Hi all
I was running SpecSFS on a 8-way machine when I encounter a situation were
find_exported_dentry() was showing up to 75% in my profiles. After some
digging, the problem was trigger when the system was under memory pressure
which cause a dramatic shrinkage in dcache entries. This shrinkage cause the
code path thats held under the BKL to be hit under a few filesystems (XFS, JFS
and EXT3).
At first glance, the BKL seem over kill since I don't see it protecting
anything that not already protected by other locks inside the code path. I
went ahead and removed the kernel lock from find_exported_dentry() and after
several hours of testing different loads and different filesystems I have yet
to see any kernel badness or
NFS call failures.
Is there anything in particular the BKL is trying to protect here or is it
safe to remove?
-JRS
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On 03/09/04 07:54:51, Jose R. Santos wrote:
> Is there anything in particular the BKL is trying to protect here or is it
> safe to remove?
Should I push this through Andrew Morton or should this go through you guys
first? Is there a particular scenario were this would be unsafe?
Looking at the code it seems there is a possibility of racing if directories
get rename or remove, but BKL doesn't seem to protect against these races, it
may slow down thing a bit to avoid them though.
I'm attaching a patch that removes BKL from find_exported_dentry(). I see a
huge improvement on SpecSFS benchmark and haven't seen any failure up to date.
Comments?
Thanks
-JRS
On 03/11/04 15:10:20, Jose R. Santos wrote:
> Looking at the code it seems there is a possibility of racing if directories
> get rename or remove, but BKL doesn't seem to protect against these races, it
> may slow down thing a bit to avoid them though.
After looking at this even further, I'm starting to get the impression that the
BKL is there in order to protect against filesystems that behave badly. I guess
this is the price for code portability across many filesystems.
Could a better choice to fix this issue be to implementing the get_dentry() for
each filesystem and making sure that it almost always returns a connected dentry?
Filesystems that don't implement it would just use the generic op.
I also have concerns about seeing this on busy SMP machines with relative small
amounts of memory and several NFS exports with very deep directories.
> I'm attaching a patch that removes BKL from find_exported_dentry(). I see a
> huge improvement on SpecSFS benchmark and haven't seen any failure up to date.
While reduces the time spent on find_exported_dentry() from 75% to less than 1%,
it seems that this may not be a very popular approach. Guess I should have done
my homework about the BKL removal subject before posting. :)
I am really interested in knowing if the BKL is there to protect against bad
filesystem or if its there for other reasons.
Thanks
-JRS
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs