Messages in this thread | | | Date | Sat, 15 Jun 2013 11:04:11 -0400 | From | Simo <> | Subject | Re: [PATCH v2 06/14] locks: don't walk inode->i_flock list in locks_show |
| |
On 06/15/2013 07:05 AM, Jeff Layton wrote: > On Fri, 14 Jun 2013 07:52:44 -0400 > Simo <idra@samba.org> 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.
| |