Interesting analysis of linux kernel threading by IBM

[Davide Libenzi]

On Sun, 23 Jan 2000, Larry McVoy wrote:
> 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.
I'll agree with You saying that mostly all apps have a worse performances 
if multithreaded, if You agree with me that there are cases that can have a
boost from it ( in SMP ).


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

I've never said that I want to change the scheduler, I've submitted a patch
for discussion.
And I've seen that there are a lot of guys for whom touching the scheduler
is like touch their girlfriend ;)


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

Sure I'll do bechmarks even if we've confused scheduler changes for application
design.

Just now I'm testing ( benchmarking ) the new version of the scheduler that use
clusterization under high ( tunable ) loads while use the linear scan for low
workloads.
AFAIS it has the performance boost of the cluster-scheduler at high workloads
as long has the same times of the linear-scheduler under low ones.

OK to stop this thread.


PS:
I've never put under discussion Your and other guys knowledge and preparation.
I know perfectly who You are as long as other famous guys writing in this list.

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/