From mboxrd@z Thu Jan  1 00:00:00 1970
From: Valdis.Kletnieks@vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 11 Mar 2015 21:48:50 -0400
Subject: Kernel Locking Question
In-Reply-To: Your message of "Wed, 11 Mar 2015 19:03:33 -0400."
	<5F652017-F161-46C2-9DAC-B2341C463832@gmail.com>
References: <5F652017-F161-46C2-9DAC-B2341C463832@gmail.com>
Message-ID: <7964.1426124930@turing-police.cc.vt.edu>
To: kernelnewbies@lists.kernelnewbies.org
List-Id: kernelnewbies.lists.kernelnewbies.org

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