Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[8.0] Make counting of IO completion work items more precise on Windows #112795

Open
wants to merge 4 commits into
base: release/8.0-staging
Choose a base branch
from

Conversation

kouvel
Copy link
Member

@kouvel kouvel commented Feb 21, 2025

Customer Impact

While upgrading a service from .NET 6 to 8, a 1p customer noticed that on Windows, the "Thread Pool Completed Work Item Count" counter values roughly doubled for the service. This is due to .NET 8 also counting queue-processing work items that were introduced in .NET 7. So, for each IO completion callback run to completion, the completed work item count may change by 1-3 or more depending on the situation. Especially in services that take small amounts of periodic traffic, the completed work item count can appear to double or triple per IO completion callback run to completion. The metric is monitored closely by the customer to monitor service health, and they would like to be able to use a more representative count that reflects actual user work items that are completed, for that purpose.

Regression?

Yes, in .NET 7 on Windows

Testing

Validated in a small test case that for IO completion handling, the count reflects the actual number of IO completion callbacks run to completion.

Risk

Low, the count after the change is similar to what it used to be in .NET 6

eduardo-vp and others added 4 commits February 21, 2025 09:35
…Pool.CompletedWorkItemCount (dotnet#106854)

* Stop counting work items from ThreadPoolTypedWorkItemQueue as completed work items

* Fix CompletedWorkItemCount

* Update src/libraries/System.Threading.ThreadPool/tests/ThreadPoolTests.cs

Co-authored-by: Koundinya Veluri <kouvel@users.noreply.github.com>

* Run CompletedWorkItemCountTest on Windows only

---------

Co-authored-by: Eduardo Manuel Velarde Polar <evelardepola@microsoft.com>
Co-authored-by: Koundinya Veluri <kouvel@users.noreply.github.com>
- Follow-up to dotnet#106854. Issue: dotnet#104284.
- Before the change, the modified test case often yields 5 or 6 completed work items, due to queue-processing work items that happen to not process any user work items. After the change, it always yields 4.
- Looks like it doesn't hurt to have more-precise counting, and there was a request to backport a fix to .NET 8, where it's more necessary to fix the issue
@kouvel kouvel added this to the 8.0.x milestone Feb 21, 2025
@kouvel kouvel requested a review from eduardo-vp February 21, 2025 18:59
@kouvel kouvel self-assigned this Feb 21, 2025
@Copilot Copilot bot review requested due to automatic review settings February 21, 2025 18:59

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot reviewed 3 out of 4 changed files in this pull request and generated no comments.

Files not reviewed (1)
  • src/libraries/System.Threading.ThreadPool/tests/System.Threading.ThreadPool.Tests.csproj: Language not supported
Comments suppressed due to low confidence (1)

src/libraries/System.Threading.ThreadPool/tests/ThreadPoolTests.cs:1271

  • The test case does not cover the decrement logic in ThreadInt64PersistentCounter. Add a test case to ensure that the decrement behavior is tested.
public static unsafe void ThreadPoolCompletedWorkItemCountTest()
Copy link
Contributor

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

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants