lkml.org 
[lkml]   [2000]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Interesting analysis of linux kernel threading by IBM
Date
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@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.072 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site