Kernel Locking Question

Kernel Locking Question

[Nicholas Krause]

Greetings All, 
After learning about kernel locking and how atomic operations are good  in terms of improving CPU scalability in terms of making  a critical region much smaller. I 
was wondering of how this would improve file system scalability and reliability if implemented in file system code for btrfs worker threads. 
Nick
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Kernel Locking Question

[Valdis.Kletnieks at vt.edu]

On Wed, 11 Mar 2015 19:03:33 -0400, Nicholas Krause said:

> was wondering of how this would improve file system scalability and
> reliability if implemented in file system code for btrfs worker threads.

Step 1: Figure out what locks are contended in actual systems.
Step 2: Determine if the scope of a contended lock can be reduced.
Step 3: ???
Step 4: Profit!

Note that improving scalability will often cause reliability issues,
because as you decompose locks into sets of smaller locks, you increase
the number of ways you can get it wrong.  The BKL, for all its uglyness,
was pretty hard to screw up.  On the other hand, we probably would never
have gotten rid of it if somebody hadn't put lockdep into the kernel.  It
was painful enough even with automated testing tools....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150311/07a00457/attachment.bin 

Kernel Locking Question

[nick]

On 2015-03-11 09:48 PM, Valdis.Kletnieks at vt.edu wrote:
> On Wed, 11 Mar 2015 19:03:33 -0400, Nicholas Krause said:
> 
>> was wondering of how this would improve file system scalability and
>> reliability if implemented in file system code for btrfs worker threads.
> 
> Step 1: Figure out what locks are contended in actual systems.
> Step 2: Determine if the scope of a contended lock can be reduced.
> Step 3: ???
> Step 4: Profit!
> 
> Note that improving scalability will often cause reliability issues,
> because as you decompose locks into sets of smaller locks, you increase
> the number of ways you can get it wrong.  The BKL, for all its uglyness,
> was pretty hard to screw up.  On the other hand, we probably would never
> have gotten rid of it if somebody hadn't put lockdep into the kernel.  It
> was painful enough even with automated testing tools....
> 
Thanks Valdis,
That makes sense to me. I was wondering however about the reader vs writer issues
in file systems too as this seems to me coming up a lot in btrfs and  other file
systems for various reasons.
Thanks Nick