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.

Sign up for GitHub

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

Jump to bottom

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
Labels
OS-Windows Performance Thinking
Milestone
Unplanned

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).

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@dvyukov dvyukov mentioned this issue Mar 15, 2016
Closed
@gopherbot
Copy link

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

gopherbot pushed a commit that referenced this issue Apr 9, 2016
@dvyukov
runtime: revert "do not call timeBeginPeriod on windows"
0435e88 
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>
@alexbrainman alexbrainman mentioned this issue Apr 10, 2016
Closed
@johnstep johnstep mentioned this issue Jan 10, 2017
Closed
@diagprov diagprov mentioned this issue Dec 5, 2018
Closed
@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

cc @aclements @prattmic @alexbrainman @mattn

@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
Contributor

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
@qiulaidongfeng qiulaidongfeng mentioned this issue Jan 11, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
OS-Windows Performance Thinking
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
10 participants
@bradfitz @zx2c4 @rsc @minux @networkimprov @dvyukov @prattmic @ianlancetaylor @gopherbot @qiulaidongfeng