Re: [PATCH v2 06/14] locks: don't walk inode->i_flock list in locks_show

[Simo]

On 06/15/2013 07:05 AM, Jeff Layton wrote:
> On Fri, 14 Jun 2013 07:52:44 -0400
> Simo <idra@xxxxxxxxx> wrote:
>
> > On 06/13/2013 04:26 PM, Jeff Layton wrote:
> > > The only real solution I can think of is to put flock locks into the
> > > blocked_list/blocked_hash too, or maybe giving them a simple hlist to
> > > sit on.
> > >
> > > I'll fix that up in the next iteration. It'll probably make flock()
> > > tests run slower, but such is the cost of preserving this procfile...
> > How hard would it be to make the procfile stuff optional ?
> > So that those that need performance can decide to not use it ?
> > Maybe even something that can be disabled at run time ? Not just compile
> > time.
> (re-adding back the cc lists...)
>
> It'd be tricky, especially if you want to do it at runtime. The
> procfile itself is not a problem per-se. The real problem is the
> tracking you have to do in order to eventually present the procfile. So
> a boot-time or compile-time switch might be reasonable, but a runtime
> switch will probably never really be.

Just to be clear, I meant for a switch to turn it off at runtime, I 
understand very well that it would be way too hard to turn on at 
runtime. But killing the perf problem might be desirable on a system you 
cannot just reboot.

> I have a new patchset that I'm testing now though that should address
> Bruce's concerns about iterating over that global list. So far, it
> seems to be at least as fast as the latest patchset I posted.
>
> It makes the (spin)locking a bit more complex, but hopefully I can
> document this well enough that it's not a great concern.
>
> Stay tuned...

Thanks Jeff,
this is very valuable work.

Simo.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/