Re: BKL removal

[Dave Hansen <haveblue@us.ibm.com>]

Oliver Neukum wrote:
 >>> I would mind the BKL a lot less if it was as well understood
 >>> everywhere as it is in VFS.  The funny part is that a lock like
 >>>  the BKL would not last very long if it were well understood or
 >>>  documented everywhere it was used.
 >>
 >> I would mind it a whole lot less if when you try to remove the
 >> BKL, you do it correctly.  So far it seems like you enjoy doing
 >> "hit and run" patches, without even fully understanding or
 >> testing your patches out (the driverfs and input layer patches
 >> are proof of that.)  This does nothing but aggravate the
 >> developers who have to go clean up after you.
 >>
 >> Also, stay away from instances of it's use WHERE IT DOES NOT
 >> MATTER for performance.  If I grab the BKL on insertion or
 >> removal of a USB device, who cares?  I know you are trying to
 >> remove it entirely out of the kernel, but please focus on places
 >> where it actually helps, and leave the other instances alone.
 >
 > If you really want to make maximum impact, do tests. Very few
 > people can measure lock contention on a 4-CPU system.

Do you mean "see lock contention", or "have the hardware to measure
lock contention"?  We probably use lockmeter more than just about 
anyone else.  But, I do not, nor have I ever contended, that things 
like driverfs's BKL use have a performance impact.  I just consider 
them messy, and bad practice.

 > And please rest assured that nobody wants to be maintainer of the
 > subsystem that ruins scalability.

I agree completely.  All of the maintainers who are handed data that 
shows bad BKL contention have either done something about it, or are 
doing something about it now.  2.5 is 2 orders of magnitude better 
than 2.4 for BKL contention in most of the workloads that I see.

 > And if you see a use of the BKL you don't understand ask first, or
 > send a patch to the subsystem's mailing list, not lkml. People will
 >  look at BKL usage if you ask. In fact such a look might even
 > uncover bugs as in case of USB.

I guess I got discouraged by a few non-responsive mailing lists in the 
past.  I'll make an effort to use them more in the future.

-- 
Dave Hansen
haveblue@us.ibm.com