New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: gc can add clock tick latency when HPETs are not used #7763

Open
4ad opened this Issue Apr 11, 2014 · 11 comments

Comments

Projects
None yet
5 participants
@4ad
Member

4ad commented Apr 11, 2014

Garbage collector can add latency on the order of clock tick (usually
10ms, 2.5ms, or 1ms) to each run.

This is due to some runtime·usleep(1) and runtime·usleep(100) calls,
which get rounded up to clock period when HPETs are not used.

More details in this thread:
https://groups.google.com/d/topic/golang-codereviews/AxqxYnioBOQ/discussion

Linux uses HPETs by default, but most ARM machines don't have HPETs.
Solaris doesn't use HPETs by default, so this issue affects arm
machines and solaris.

I'm not sure if we need to do anything (maybe we can just assume
"fast" machines), I'm logging it so we can refer to it later.
@davecheney

This comment has been minimized.

Contributor

davecheney commented Apr 11, 2014

Comment 1:

Thanks Aram. Are you saying the underlying issue is runtime.usleep(100us) sleeps for
much longer than expected ?

Labels changed: added release-go1.3, repo-main.

Status changed to Accepted.

@4ad

This comment has been minimized.

Member

4ad commented Apr 11, 2014

Comment 2:

Yes, at the moment it gets rounded up to 10ms on Solaris. I haven't measured on
linux/arm, I expect it to be 2.5ms.
For Solaris, I'll change the runtime to use HPETs (although that has other issues), for
linux/arm we can't do this because there are no HPETs.
@4ad

This comment has been minimized.

Member

4ad commented Apr 11, 2014

Comment 3:

I'd expect Windows XP SP2 (not SP3) also to not support high resolution sleeps at all.
@4ad

This comment has been minimized.

Member

4ad commented Apr 11, 2014

Comment 4:

And of course by 2.5ms I wanted to say 4ms (250Hz).
@davecheney

This comment has been minimized.

Contributor

davecheney commented Apr 11, 2014

Comment 5:

Here are some sample numbers for the observed delay of usleep(1) 
% uname -a
Linux lucky 3.11.0-19-generic #33-Ubuntu SMP Tue Mar 11 18:48:34 UTC 2014 x86_64 x86_64
x86_64 GNU/Linux
% cc time.c && ./a.out
usleep(1) took 72298 ns
panda(~) % uname -a 
Linux panda 3.7.10-x13 #1 SMP Wed Jun 26 07:33:15 UTC 2013 armv7l GNU/Linux
panda(~) % cc time.c && ./a.out
usleep(1) took 122070 ns
In both cases these represent the best results I have seen, during some runs I have seen
the arm numbers spike to 150us and the amd64 numbers spike to 140us

Attachments:

  1. time.c (379 bytes)
@4ad

This comment has been minimized.

Member

4ad commented Apr 11, 2014

Comment 6:

What's CONFIG_HZ, CONFIG_NO_HZ and HIGH_RES_TIMERS on this kernel? What in these files?
/sys/devices/system/clocksource/*/current_clocks
@dvyukov

This comment has been minimized.

Member

dvyukov commented Apr 11, 2014

Comment 7:

runtime·usleep(1) and runtime·usleep(100) are really intended to be more like
scheduler yields, rather than sleeps
if the system can't handle them, it can just do scheduler yield
@4ad

This comment has been minimized.

Member

4ad commented Apr 11, 2014

Comment 8:

> runtime·usleep(1) and runtime·usleep(100) are really intended to be more
> like scheduler yields, rather than sleeps if the system can't handle them,
> it can just do scheduler yield
Indeed, replacing sleeps with yields solves the problem:
http://paste.ubuntu.com/7234785/
@gopherbot

This comment has been minimized.

gopherbot commented Apr 12, 2014

Comment 9:

CL https://golang.org/cl/87290043 mentions this issue.
@rsc

This comment has been minimized.

Contributor

rsc commented Apr 14, 2014

Comment 10:

Labels changed: added release-go1.4, removed release-go1.3.

@rsc

This comment has been minimized.

Contributor

rsc commented Sep 18, 2014

Comment 11:

Labels changed: added release-none, removed release-go1.4.

@4ad 4ad added accepted labels Sep 18, 2014

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed release-none labels Apr 10, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment