Re: Negative scalability by removal of lock_kernel()?(Was: Strange performance behavior of 2.4.0-test9)

Andi Kleen
2000-10-27T07:46:33Z

On Fri, Oct 27, 2000 at 03:13:33AM -0400, Alexander Viro wrote:
> I didn't look into recent changes in fs/locks.c, but I have quite problem
> inventing a scenario when _adding_ BKL (without reverting other changes)
> might give an absolute improvement. Well, I see a couple of really perverted
> scenarios, but... Seriously, folks, could you compare the 4 variants above
> and gather the contention data for the -test9 on your loads? That would help
> a lot.

I think it is easy to see. Switching between CPUs for criticial section
always has an latency because the lock/data update needs some time to cross
the bus

When you have two CPUs contending on common paths it is better to do:

CPU #0 CPU #1

grab big lock spin
do thing
release big lock ----> latency ---> grab big lock
do thing
do other things ....

than to do

grab small lock 1 spin
do small thing
release small lock 1 --> latency --> get small lock
do small thing
release lock
<--- latency ---
get small lock, fetch data
do small thing
release lock
---> latency ---> get small lock
do small thing
release lock
<--- latency ----

etc. The latencies add up and they're long because they're bus limited.
For common paths it is definitely useful to have bigger lock sections.

-Andi