Messages in this thread | | | From | Davide Libenzi <> | Subject | Re: Interesting analysis of linux kernel threading by IBM | Date | Sun, 23 Jan 2000 20:55:28 +0100 |
| |
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/
| |