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
[email protected]
> > 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
Both, most use UP exclusively. You know, SMP costs serious money.
Actually very few people can walk over to some colleagues to gain access
to a 16-CPU box.
> 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.
Then show some creativity, if you must publish statistics on subsystems
having most inexplicable uses of the BKL. Make it a challenge, not an attack.
> > 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.
Good - which lock is next in your noble quest for scalability?
> > 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.
Yes, please. "Linus, let's rip out some random locks which offend my sense
of beauty" tends to piss off people. Linus might even agree, but you don't
enjoy His Excellency's priviledges ;-)
Regards
Oliver