[lkml]   [2013]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v6 3/5] qrwlock: Enable fair queue read/write lock
> Why would it make sense here?

There may be cases were switching all read locks to unfair may make
concerete workloads slower.

The effect is very visible in (non kernel) lock micro benchmarks,
especially with HyperThreading.

With very high contention or long enough critical sections
the ordered lock usually wins, but it loses with lower contention.

Unfortunately the "small critical section" case (even though it's
really bad for any contended lock) is reasonably common :-/
[IMHO all of these should be fixed or "batched" somehow, but in some
cases it is quite hard]

However ordered locks definitely have more consistent performance.
If prioritizing consistency over potential slow down in some cases
is fine only having the ordered option is ok.


 \ /
  Last update: 2013-11-18 21:01    [W:0.050 / U:1.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site