Interesting analysis of linux kernel threading by IBM

[Larry McVoy]

: > No, yet again the _app_ design you propose is the bottleneck.
: 
: I'll respect Your opinion but the mine is different.

I spent the day yesterday cutting down a tree (a college era skill I
aquired, long story), so I just went through all the mail on this 
thread.

Somebody, apologies for not remembering who, said this is turning into
a "he said, she said" type of argument and I have to agree.

At this point, Davide, it has been made clear that there are a number
of people who have experience and are saying that your approach has
a strong chance of being, err, less than optimal.  You and the other
fix-the-scheduler people seem pretty insistent that it is the right
thing to do.

The other side is saying ``this application design will yield poor
performance, and in general, we believe that the right number of active
processes or threads is N | N == #CPUS perhaps plus a small number of
controller threads.''

Given that there is enough controversy on both sides, and that you want
the scheduler to change over the objects of a number of experienced people
who believe that it's a bad idea, I think it is reasonable to ask that
you demonstrate that your application does indeed perform better with
your model.  So please code up a pair of benchmarks, one which does
all the work in one thread (but can have N concurrent threads running)
and one that does the work in the pipeline.  If you can show that the
model you propose has _BETTER_ performance than the other model, then
there is indeed a good reason to consider the scheduler changes.  If the
performance is worse, or even the same, then there really is not much
reason to make any changes.  If the performance were the same in both
cases, you could argue that the threaded model has a nicer programming
model and we should support it.  Let's cross that bridge when we come
to it, the first step is to get the benchmarks.

I strongly feel that since you are pushing for this, the benchmarks are
something you need to do.  You are perfectly qualified to do them because
you understand your application, and I at least, apparently don't.  So
please come forward with the benchmarks and the results and until then,
let's drop this topic.  I think we've pushed it as far as we can in this
forum.  Any objections from anyone?

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