On 09/11/2018 04:17 AM, Peter Zijlstra wrote: > On Mon, Sep 10, 2018 at 10:15:50AM -0700, Davidlohr Bueso wrote: >> On Mon, 10 Sep 2018, Waiman Long wrote: >> >>> One major issue with a combined count/owner is that we may have to use >>> cmpxchg for reader lock which will certainly impact reader-heavy >>> workloads. I have also thought about ways to compress the task pointer >>> address so that it can use fewer bits and leave the rests for reader >>> count. It is probably doable on 64-bit systems, but likely not on 32-bit >>> system given that there are less bits to play around. >> Yeah we've discussed this before. As a cleanup it would obviously be good, >> but I fear about raw performance loss when using cmpxchg instead of xadd. > Does it really matter though? Last time I looked at something similar > (refcount_t) the "LOCK INCL" vs "LOCK CMPXCHG" was something like 15 vs > 23 cycles (and that was with the cmpxchg loop actually doing a lot > more). > > Do we really care about the down_read() path _that_ much? I thought that > with the main pain point, pagefaults, the problem was mostly the line > bouncing, not a few extra cycles.
It is not simply that cmpxchg needs more cycles to run, it is the fact that a few retries may be necessary to actually increment the count in case of contention leading to more RMW cycles than with xadd. I am not saying that we can't do that, but there is a price we need to pay. Cheers, Longman
