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

Reduce the number of thread requests further in the thread pool and from async IO completion dispatchers #93028

Closed
kouvel opened this issue Oct 4, 2023 · 1 comment · Fixed by #100506
Labels
area-System.Threading in-pr There is an active PR which will close this issue when it is merged
Milestone

Comments

@kouvel
Copy link
Member

kouvel commented Oct 4, 2023

  • Currently, when just one work item is queued to the thread pool, two threads are released. When just one async IO completes, three threads are released.
  • In async IO completion dispatchers such as this, don't parallelize dispatching unless there is actually another work item to process
  • Similarly in the thread pool work item dispatcher, don't parallelize dispatching unnecessarily. In the thread pool dispatcher, another work item could be dequeued and set aside before parallelizing, the next thread would process the work item that was set aside (or some other thread would pick up the work item).
  • Both use similar parallelizing schemes, investigate modifying the schemes to 3-stage schemes to avoid an enqueuer from requesting a thread while another thread is already looking for work to determine whether to parallelize further. This would ensure that threads are requested sequentially, and avoid overeager parallelization in some cases.
  • These should help to reduce CPU usage in scenarios where the thread pool gets periodic short bursts of work
  • May also be relevant to:
@kouvel kouvel added this to the 9.0.0 milestone Oct 4, 2023
@ghost
Copy link

ghost commented Oct 4, 2023

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

Issue Details
  • In async IO completion dispatchers such as this, don't parallelize dispatching unless there is actually another work item to process
  • Similarly in the thread pool work item dispatcher, don't parallelize dispatching unnecessarily. In the thread pool dispatcher, another work item could be dequeued and set aside before parallelizing, the next thread would process the work item that was set aside (or some other thread would pick up the work item if there are no other work items).
  • Both use similar parallelizing schemes, investigate modifying the schemes to 3-stage schemes to avoid an enqueuer from requesting a thread while another thread is already looking for work to determine whether to parallelize further. This would ensure that threads are requested sequentially, and avoid overeager parallelization in some cases.
  • These should help to reduce CPU usage in scenarios where the thread pool gets periodic short bursts of work
  • Also relevant to async sockets in linux (windows is fine) use 5-8x expected cpu vs synchronous sockets or comparables in other languages #72153
Author: kouvel
Assignees: -
Labels:

area-System.Threading

Milestone: 9.0.0

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Threading in-pr There is an active PR which will close this issue when it is merged
Projects
None yet
1 participant