[lkml]   [2018]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 03/10] locking: bring back lglocks
On Fri, May 18, 2018 at 11:51:02AM +0200, Peter Zijlstra wrote:
> On Fri, May 18, 2018 at 03:49:04AM -0400, Kent Overstreet wrote:
> > bcachefs makes use of them - also, add a proper lg_lock_init()
> Why?! lglocks are horrid things, we got rid of them for a reason. They
> have terrifying worst case preemption off latencies.

Ah. That was missing from your commit message.

> Why can't you use something like per-cpu rwsems?


a) in my use case, lg_global_lock() pretty much isn't used in normal operation,
it's only called when starting mark and sweep gc (which is not needed
anymore and disabled by default, it'll eventually get rolled into online
fsck) and for device resize

b) I'm using it in conjection with percpu counters, and technically yes I
certainly _could_ use per-cpu sleepable locks (mutexes would make more sense
for me than rwsems), there's a bit of a clash there and it's going to be a
bit ugly and messy and it's more work for me. (this_cpu_ptr() no longer
makes any sense in that case, so it'd mean auditing and converting all the
code that touches the relevant data structures).

If you're really that dead set against lglocks I might just come up with a new
lock with similar semantics, that doesn't break this_cpu_ptr() but sleeps if the
global lock is held...

 \ /
  Last update: 2018-05-18 12:15    [W:0.096 / U:4.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site