Re: [PATCH] sched.c: Be a bit more conservative in SMP
- From: Vincent Pelletier <vincent.plr@xxxxxxxxxx>
- Date: Thu, 21 Sep 2006 20:36:18 +0200
Le mercredi 20 septembre 2006 09:42, Ludovic Drolez a écrit :
Yes ! That might be a better idea !
In fact, I tested the 1st patch on our cluster (Finite elements computing
on 8 CPUs):
- Under Windows: 875 seconds
- Linux 2.6.16 : 1019 s
- Linux 2.6.16 + manual taskset : 842 s
- Linux 2.6.16 + Vincent's patch : 1373 s :-(
I was afraid of this :/.
I did some quick tests, and I got non-significant results. I tried building a
kernel with different make -j parameters, and there was like a few seconds of
difference, and not always in favour of the same version.
I find it strange that you get such horrible results...
Maybe I was completely wrong with my assumption that one running process
always has an impact of 1, which would have make the scheduler underestimate
the load on one cpu and put too many processes on it, without moving them
afterward.
--
Vincent Pelletier
Attachment:
pgpH0R1GqC6He.pgp
Description: PGP signature
- Follow-Ups:
- Re: [PATCH] sched.c: Be a bit more conservative in SMP
- From: Ludovic Drolez
- Re: [PATCH] sched.c: Be a bit more conservative in SMP
- References:
- [PATCH] sched.c: Be a bit more conservative in SMP
- From: Vincent Pelletier
- Re: [PATCH] sched.c: Be a bit more conservative in SMP
- From: Antonio Vargas
- Re: [PATCH] sched.c: Be a bit more conservative in SMP
- From: Ludovic Drolez
- [PATCH] sched.c: Be a bit more conservative in SMP
- Prev by Date: Re: [PATCH 1/2] block: support larger block pc requests take 2
- Next by Date: [PATCH 2.6.18] xpad: dance pad support
- Previous by thread: Poor scheduling when not loaded at 100% (Was: [PATCH] sched.c: Be a bit more conservative in SMP)
- Next by thread: Re: [PATCH] sched.c: Be a bit more conservative in SMP
- Index(es):
Relevant Pages
|
