Re: [PATCH 2/7] fs/locks: Replace lg_global with a percpu-rwsem

[Andreas Mohr <andi@lisas.de>]

On Tue, Sep 06, 2016 at 10:23:28AM +0200, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 03:58:00AM +0200, Andreas Mohr wrote:
> > Hi,
> > 
> > [no properly binding reference via In-Reply-To: available thus manually re-creating, sorry]
> > 
> > https://lkml.org/lkml/2016/9/5/832
> 
> Subscribe to lkml already.. also lkml.org is near useless these days,
> please use any other archive.

I cannot count the number of times that I did so
(sometimes directly failing, sometimes getting dropped after few weeks).
Hopefully with that other address things will now work out ok...


There might be further archives (other than gmane.org or some such),
however so far lkml.org seemed to be quite ok
and with IMHO better usability than some others
(although it has degraded a lot indeed in recent times,
judging from
many server/connection issues and
not listing details any more due to SPAM etc.).


> > A possibly good way to commit-micro-manage this would be:
> > 1. commit shoves things into a newly created encapsulation/wrapper helper
> >    stuff_lock(&flc_lock);  /* <---- naming surely can be improved here */
> 
> No, because not all instances of flc_flock need the percpu-rwsem held,
> creating such a wrapper could mistakenly create the impression it
> should.

OK, that aspect sounds valid.
However with a helper appropriately named to be focussing on
that use case (protecting that section communication),
it might be less of a concern.


> lockdep is rather good at finding those, also might_sleep() debugging
> would trivially catch those since percpu-rwsem is a sleeping lock while
> fcl_flock is not.

So perhaps the only thing left to argue on my side is
that this way it would be
n+1 vs. n protection mechanisms ;)
(with some of those n+1 mechanisms
known to be failing one time or another...)

Thanks,

Andreas Mohr