Re: BKL removal

[Oliver Neukum <oliver@neukum.name>]

>  > 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