[SERVER-29534] the unaligned variables in counter.h contribute to high use contention Created: 09/Jun/17  Updated: 30/Oct/23  Resolved: 07/Jul/17

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: 3.5.10

Type: Improvement Priority: Major - P3
Reporter: Jim Van Fleet Assignee: Andrew Morrow (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-29712 Polyfill std::hardware_{con,de}struct... Closed
Backwards Compatibility: Fully Compatible
Sprint: Platforms 2017-07-10
Participants:

 Description   

In counters.h, the variables with types AtomicUInt32 and AtomicInt64 need to be cache line aligned. as the comment says, "there will be a lot of cache line contention on these." false sharing with these counters creates significant contention when loads are high.



 Comments   
Comment by Githook User [ 07/Jul/17 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@mongodb.com'}

Message: SERVER-29534 Place network and op counters on independent cache lines
Branch: master
https://github.com/mongodb/mongo/commit/be4c4f1fffe6ca69fb67ee872b52b3bd4e630659

Comment by Jim Van Fleet [ 27/Jun/17 ]

I can not say I have tested the changes directly, but I have run a number of experiments with the changed code. None of the tests showed negative leanings.

The test that prompted this change is not available to me at this time, so I am disappointed in not being able to provide that feedback..

Comment by Andrew Morrow (Inactive) [ 17/Jun/17 ]

Hi jvf -

Could you please re-run your experiment that indicated false sharing on these counters with the following branch:

https://github.com/acmorrow/mongo/commits/partition-no-false-sharing

Note that this branch also spaces out the striped locks in the cursor manager lock partition, so I think it might be interesting to see if you can find any increased throughput or reduced cache ping-ponging with this branch on whatever workload you were using to look at the scalability in that component.

If possible, I recommend you A/B testing this against the prior commit on that branch, so we aren't comparing apples to oranges - there have been a lot of other changes committed on master recently.

Generated at Thu Feb 08 04:21:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.