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: use user-mode scheduling on Windows #7876

Open
dvyukov opened this Issue Apr 27, 2014 · 3 comments

Comments

Projects
None yet
5 participants
@dvyukov
Member

dvyukov commented Apr 27, 2014

Runtime could benefit from OS support for user-mode scheduling.
Namely, UMS on windows:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd627187(v=vs.85).aspx
and switchto domains on linux:
http://www.youtube.com/watch?v=KXuZi9aeGTw

This would allow to determine when a thread in syscall/cgocall actually block. Which
would allow to reduce non-blocking syscall/cgocall overhead by delaying most of the work
till the actual blocking; and to prevent CPU oversubscription by maintaing total of
GOMAXPROCS threads running both Go and C/syscall code.

The obvious downside is increased complexity and lots of OS-specific code.
@minux

This comment has been minimized.

Member

minux commented Apr 27, 2014

Comment 1:

maintaining total GOMAXPROCS threading running both go and cgo code
will break at least one misc/cgo/test case though.
However, if we count goroutines running cgo code towards to GOMAXPROCS,
then I think we can dramatically reduce cgocall overhead (no scheduler coordination
except mark that it enters cgocall). Am I correct?
@dvyukov

This comment has been minimized.

Member

dvyukov commented Apr 28, 2014

Comment 2:

You are correct.
To prevent deadlocks scheduler can still create new threads to run Go, but much more
lazily (so that it mostly does not happen for normal programs).
@gopherbot

This comment has been minimized.

gopherbot commented Mar 18, 2016

CL https://golang.org/cl/20834 mentions this issue.

gopherbot pushed a commit that referenced this issue Apr 9, 2016

runtime: revert "do not call timeBeginPeriod on windows"
This reverts commit ab4c929.

Sysmon critically depends on system timer resolution for retaking
of Ps blocked in system calls. See #14790 for an example
of a program where execution time goes from 2ms to 30ms if
timeBeginPeriod(1) is not used.

We can remove timeBeginPeriod(1) when we support UMS (#7876).

Update #14790

Change-Id: I362b56154359b2c52d47f9f2468fe012b481cf6d
Reviewed-on: https://go-review.googlesource.com/20834
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

@bradfitz bradfitz added the OS-Windows label Nov 21, 2018

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