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- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 07 2002 - 22:00:18 EST