Linux-kernel mailing list archive 2000-04,: Re: Interesting analysis of linux kernel threading by IBM

# Re: Interesting analysis of linux kernel threading by IBM

Davide Libenzi (dlibenzi@maticad.it)
Sun, 23 Jan 2000 20:55:28 +0100

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Albert Cranford: "[PATCH] fix for cdrom.c implicit decl WARNING"
- Previous message: Jonathan Disher: "Re: Newbie question on iso9660: files partially AWOL ?"
- In reply to: Larry McVoy: "Re: Interesting analysis of linux kernel threading by IBM"
- Next in thread: Marco Colombo: "Re: Interesting analysis of linux kernel threading by IBM"
- Next in thread: James A Simmons: "Re: Interesting analysis of linux kernel threading by IBM"
- Reply: Marco Colombo: "Re: Interesting analysis of linux kernel threading by IBM"

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/

- Next message: Albert Cranford: "[PATCH] fix for cdrom.c implicit decl WARNING"
- Previous message: Jonathan Disher: "Re: Newbie question on iso9660: files partially AWOL ?"
- In reply to: Larry McVoy: "Re: Interesting analysis of linux kernel threading by IBM"
- Next in thread: Marco Colombo: "Re: Interesting analysis of linux kernel threading by IBM"
- Next in thread: James A Simmons: "Re: Interesting analysis of linux kernel threading by IBM"
- Reply: Marco Colombo: "Re: Interesting analysis of linux kernel threading by IBM"