Messages in this thread | | | Subject | Re: [PATCH v4 12/16] locking/rwsem: Enable time-based spinning on reader-owned rwsem | From | Waiman Long <> | Date | Fri, 19 Apr 2019 11:36:44 -0400 |
| |
On 04/19/2019 10:33 AM, Waiman Long wrote: > On 04/19/2019 03:56 AM, Peter Zijlstra wrote: >> On Thu, Apr 18, 2019 at 11:15:33AM -0400, Waiman Long wrote: >>> On 04/18/2019 09:06 AM, Peter Zijlstra wrote: >>>>> + /* >>>>> + * Check time threshold every 16 iterations to >>>>> + * avoid calling sched_clock() too frequently. >>>>> + * This will make the actual spinning time a >>>>> + * bit more than that specified in the threshold. >>>>> + */ >>>>> + else if (!(++loop & 0xf) && >>>>> + (sched_clock() > rspin_threshold)) { >>>> Why is calling sched_clock() lots a problem? >>> Actually I am more concern about the latency introduced by the >>> sched_clock() call. BTW, I haven't done any measurement myself. Do you >>> know how much cost the sched_clock() call is? >>> >>> If the cost is relatively high, the average latency period after the >>> lock is free and the spinner is ready to do a trylock will increase. >> Totally depends on the arch or course :/ For 'sane' x86 it is: RDTSC, >> MUL; SHRD; SHR; ADD, which is plenty fast. >> >> I know we have poll loops with sched_clock/local_clock in them, I just >> can't seem to find any atm. > Thanks, I will do some time measurement myself. If it is fast enough, I > can change the code to do sched_clock on every iteration. > > Cheers, > Longman > I had measured the time of doing 10 sched_clock() calls. On a 2.1GHz skylake system, it was 83ns (~18 cycles per call). On a 2.5GHz Thunder X2 arm system, it was 860ns (~215 cycles per call). On a 2.2GHz AMD EPYC system, it was 200ns (~44 cycles per call). Intel is fastest, followed by AMD and then the ARM64 chip.
Cheers, Longman
| |