Skip to content
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

Closed
dvyukov opened this issue Apr 27, 2014 · 8 comments
Closed

runtime: use user-mode scheduling on Windows #7876

dvyukov opened this issue Apr 27, 2014 · 8 comments

Comments

@dvyukov
Copy link
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
Copy link
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
Copy link
Member Author

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
Copy link
Contributor

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

gopherbot pushed a commit that referenced this issue Apr 9, 2016
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 <[email protected]>
Run-TryBot: Dmitry Vyukov <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Alex Brainman <[email protected]>
@zx2c4
Copy link
Contributor

zx2c4 commented Nov 27, 2020

I'm wondering if there's still interest in doing this, given the evolution of the runtime in the last 6 years. At cursory glance, it looks appealing.

@networkimprov
Copy link

@ianlancetaylor
Copy link
Contributor

According to #8687 (comment) User Mode Scheduling is considered to be deprecated, and will not be supported on ARM platforms.

So I suspect we should just close this issue.

@qiulaidongfeng
Copy link
Member

cc @golang/runtime
windows 11 not support UMS , this issue should be close.

@prattmic
Copy link
Member

Thanks. This is clearly documented are unsupported on https://learn.microsoft.com/en-us/windows/win32/procthread/user-mode-scheduling?redirectedfrom=MSDN.

@prattmic prattmic closed this as not planned Won't fix, can't repro, duplicate, stale Jan 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants