time:infinite-loop with time.sleep cause high cpu usage

[kdada]

1. What version of Go are you using (go version)?
   go version go1.6 linux/amd64
2. What operating system and processor architecture are you using (go env)?
   CentOS Linux release 7.1.1503 (Core)
   Linux 3.10.0-229.el7.x86_64 cmd/cgo: fails with gcc 4.4.1 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
   CPU i5 6500
   RAM 8G

i want to do something every millisecond,so i write:

package main

import "time"

func main() {
    for true {
        time.Sleep(time.Millisecond)
    }
}

i build & run it on centos 7,than i use top to watch the usage of the application,it shows:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22789 root 20 0 2704 780 432 S 7.3 0.0 0:00.53 test

why it can cause high cpu usage?

[davecheney]

Hello,

Thank you for your report.

I believe this is an operating system issue for a bug in top.

The program you wrote is technically an infinite loop (assuming time is infinite and thus can be slept in discreet quantities), and as such we cannot accept it as a bug report. It's unlikely that you want to write a program that just sleeps for a short amount of time, so you probably are writing another kind of program when you discovered this issue. FWIW, if you want to pause a goroutine, use

select {}

In the future, the best place to discuss this issue is on another forum, you can find more details on this page. https://github.com/golang/go/wiki/Questions

To the question at hand. Thank you for providing sample code, it is much appreciated. I have run your sample code and found that on my system top reports around 15% cpu usage for the test binary. However, for the overall system stats usage is about 3% as reported by top and by vmstat. This program generates somewhere between 5000 and 7000 context switches per second, waking roughly every 10 milliseconds, which is the resolution of the system timer on this machine. 3% cpu for 7k context switches / second is reasonable by my standards.

I'm going to close this as working as intended for the moment as I do not believe the issue is with Go. If you disagree, please feel free to reopen it, but please consider first discussing your question via one of the links provided above.

Thanks

Dave