Interesting analysis of linux kernel threading by IBM

[Davide Libenzi]

Hi Larry,

Friday, January 21, 2000 5:01 AM
Larry McVoy <lm en bitmover.com> wrote :
> Whatever, can the people who are really interested in high performance
> take a look at
>
> http://www.bitmover.com/llnl/smp.{ps,pdf}
> and then
> http://www.bitmover.com/llnl/labs.{ps,pdf}

I've just taken up and printed the doc, I'll read it this weekend.

> Premise 1: SMP scaling is a bad idea beyond a very small number
processors.
>     The reasoning for this is that when you start out threading a kernel,
>     it's just a few locks.  That quickly evolves into more locks, and
>     for a short time, there is a 1:1 mapping between each sort of object
>     in the system (file, file system, device, process, etc) and a lock.
>     So there can be a lot of locks, but there is only one reader/writer
>     lock per object instance.  This is a pretty nice place to be - it's
>     understandable, explainable, and maintainable.
>
>     Then people want more performance.  So they thread some more and now
>     the locks aren't 1:1 to the objects.  What a lock covers starts to
>     become fuzzy.  Thinks break down quickly after this because what
>     happens is that it becomes unclear if you are covered or not and
>     it's too much work to figure it out, so each time a thing is added
>     to the kernel, it comes with a lock.  Before long, your 10 or 20
>     locks are 3000 or more like what Solaris has.  This is really bad,
>     it hurts performance in far reaching ways and it is impossible to
>     undo.

IMHO, every good technology if bad applied or exasperated will give worse
results.
I continue to disagree with You here, but perhaps we're speaking of two
different things.
I' m speaking about a fine applied multiprocessing and You probably of an
exasperation of it.
But I like to disagree with someone about technical issues, I'm always
happy.
If I'w right I'm pleased with myself for my good view of the fact, and if
I'm wrong I'm happy
coz I learn more about ;)

Cheers,
    Davide.

--
All this stuff is IMVHO




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/