[lkml]   [2009]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 04/33] fs: brlock vfsmount_lock
On Sun, 2009-09-27 at 21:56 +0200, Nick Piggin wrote:
> On Tue, Sep 22, 2009 at 04:17:51PM +0100, Al Viro wrote:
> > On Fri, Sep 04, 2009 at 04:51:45PM +1000, wrote:
> > > Use a brlock for the vfsmount lock.
> >
> > I like it, but I'd like to see how costly it becomes on heavily SMP boxen.
> > Creation/removal of bindings as load...
> I could test that... Is there some realistic scenario I can try
> to implement that exercises this? (failing that, I'll happily
> do a microbenchmark).
> I was thinking it *might* be possible to do RCU... but especially
> coming up with a scheme that avoids synchronize_rcu() in the
> umount path is not trivial, so perhaps the simple read/write
> annotations with brlock behind the scenes is a more reasonable step.
> I do also actually owe you some documentation with this one too,
> which I will get around to adding.

The thing that worries me is that the write-side is very heavy and the
read sides are spinning on it, yielding rather large spin times on large
smp boxen.

It wouldn't nearly be as bad if the read sides could block..

FWIW, spin_lock_nested is limited to 8 subclasses, so your current
implementation will explode on anything larger than an 8-way.

 \ /
  Last update: 2009-09-28 15:23    [W:0.076 / U:25.132 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site