Tracking issue for threading work items

[kouvel]

• Using less power when appropriate on machines with heterogenous cores
  • The thread pool parallelizes fairly quickly and likely causes cores to be unparked or for threads to be switched to a performance core. The goal is to experiment with a couple of ideas that may work and to measure the effects.
  • Identify a mobile device scenario to improve and measure the current performance and power
  • Experiment with using the online core count to limit concurrency while still being able to unpark cores if necessary for performance
  • Experiment with spin-waiting less and measure power usage
• Further investigate the perf regressions from processing IO events at higher priority on Unixes. Tracking issue for some thread pool experiments (.NET 8) #77665
• Hill climbing
  • Disable hill climbing by default for a few previews and gather feedback
  • Consider an alternative, to identify individual threads that appear to be stalled and responding more quickly similarly to cooperative blocking
• The overhead of work stealing is high, especially in bursty scenarios or in cases where the thread count is high, when threads are all trying to determine that there is no work left. Reduce time in .NET Threadpool's WorkStealingQueue.TrySteal method and ThreadPoolWorkQueue.Dequeue methods.  #10752

Completed

• Remove the native thread pool. Move timer implementation to libraries. Remove ThreadPool native implementation #71719
• The thread pool's global queue does not scale well on machines with a large number of processors with one or more numa nodes. Attempt to make work items more local with appropriate ordering, or other techniques. The thread pool's global queue doesn't scale well on machines with a large processor count #67845, Fix some scaling issues with the global queue in the thread pool #69386
• Add Windows IO completion handling to the portable thread pool. Add support for Windows IO completions to the portable thread pool #64834
• Thread pool requests too many threads. Thread pool's thread request code is logically flawed (Thread pool - Fix a couple of things that were reverted #8951). It performs poorly in bursty scenarios and in low-load situations.
• Spin-waiting on arm processors is insufficient. Actionable, dependency for next item due to perf regressions. Maybe spin-waits in the thread pool can be tuned better for arm/arm64 #39559
• Change spin-waiting normalization to not depend on values measured at startup. Change spin-waiting normalization to not depend only on values measured at startup #53509
• Increase rate of thread injection for blocking due to sync-over-async. Improve the rate of thread injection for blocking due to sync-over-async #52558
• Fix Environment.ProcessorCount to behave on Windows similarly to Linux in CPU-limited environments. Make the value configurable. [Breaking change] Environment.ProcessorCount on Windows takes processor affinity into account #47427, Enable Environment.ProcessorCount to return total machine processors in containers #48094

[davidfowl]

@kouvel do you want to link some of the other work items.

[mangod9]

Thanks for listing these. Couple of questions:

1. Are these in priority order?
2. Would be good to determine which will make it into .net 6 preview 7 timeframe
3. First and last items are basically the same?

[kouvel]

Are these in priority order?

These are not in any particular order, I believe they are all worth doing.

Would be good to determine which will make it into .net 6 preview 7 timeframe

Other than the checked item, "Increase rate of thread injection for blocking due to sync-over-async" and "Fix spin-waiting to not depend on values measured at startup" are the currently scheduled items.

First and last items are basically the same?

The last one is specific to sync-over-async and works a bit differently. There is some overlap between them.