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:
pgpZY4MEMa6wi.pgp
Description: PGP signature
- Follow-Ups:
- Re: [PATCH] sched.c: Be a bit more conservative in SMP
- From: Ludovic Drolez <[email protected]>
- 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 <[email protected]>
- Re: [PATCH] sched.c: Be a bit more conservative in SMP
- From: "Antonio Vargas" <[email protected]>
- Re: [PATCH] sched.c: Be a bit more conservative in SMP
- From: Ludovic Drolez <[email protected]>
- [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):
 |