Uh oh!
There was an error while loading. Please reload this page.
Remap thread id to avoid bitmap contention - #223
Conversation
🔧 Report generated by pr-comment-scanbuild |
r1viollet
commented
Jun 11, 2025
Would the contention not remain if you only swap lower bits ? |
r1viollet
commented
Jun 11, 2025
I think the proposal here is still performing better: Versus this one: As a first step can we deliver the bench in a separate PR to get it running in CI ? This way, we could get more stable results. My laptop has a lot of noise. |
r1viollet
commented
Jun 11, 2025
Also a different bench would be interesting. |
zhengyu123
commented
Jun 13, 2025
As discussed, I updated PR to reverse lower 32 bits that will further more distant 2 consecutive number to ensure they are not mapped to the same cache line. |
Uh oh!
There was an error while loading. Please reload this page.
jbachorik
left a comment
There was a problem hiding this comment.
How do the benchmarks look with the latest changes?
Otherwise, LGTM!
zhengyu123
commented
Jun 16, 2025
jbachorik
commented
Jun 18, 2025
Is this superseded by #229 ? |


What does this PR do?:
An application starts a few threads in short period of window, the newly created threads are likely to have consecutive or close thread ids. When
ThreadFiltermaps them to the bits on bitmap, there are high chances that they may be mapped to a single cache line, that results cache line contention when updating the bitmap concurrently.The PR purposes to remap thread id by reversing lower 2 bytes of thread id, so that consecutive/close thread ids map to different cache lines.
The reason for only reversing lower 2 bytes, is that, thread id is remapped within the same bitmap.
Motivation:
Reduce cache line contention, improve performance.
Additional Notes:
How to test the change?:
For Datadog employees:
credentials of any kind, I've requested a review from
@DataDog/security-design-and-guidance.Unsure? Have a question? Request a review!