CFS scheduler, -v8
in [Kernel]
|
Prev: Bug in current -git tree causing dbus and gnome to chew up cpu time
Next: Introduce O_CLOEXEC (take >2)
From: Mike Galbraith on 2 May 2007 04:10 On Tue, 2007-05-01 at 23:22 +0200, Ingo Molnar wrote: > - interactivity: precise load calculation and load smoothing This seems to help quite a bit. (5 second top sample) 2636 root 15 -5 19148 15m 5324 R 73 1.5 1:42.29 0 amarok_libvisua 5440 root 20 0 320m 36m 8388 S 18 3.6 3:28.55 1 Xorg 4621 root 20 0 22776 18m 4168 R 12 1.8 0:00.63 1 cc1 4616 root 20 0 19456 13m 2200 R 9 1.3 0:00.43 0 cc1 I no longer have to renice both X and Gforce to achieve a perfect display when they are sharing my box with a make -j2. X is displaying everything it's being fed beautifully with no help. I have to renice Gforce (amarok_libvisual), but given it's very heavy CPU usage, that seems perfectly fine. No regressions noticed so far. Box is _very_ responsive under load, seemingly even more so than with previous releases. That is purely subjective, but the first impression was very distinct. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Gene Heskett on 2 May 2007 04:10 On Wednesday 02 May 2007, Mike Galbraith wrote: >On Tue, 2007-05-01 at 23:22 +0200, Ingo Molnar wrote: >> i'm pleased to announce release -v8 of the CFS scheduler patchset. (The >> main goal of CFS is to implement "desktop scheduling" with as high >> quality as technically possible.) > >... > >> As usual, any sort of feedback, bugreport, fix and suggestion is more >> than welcome, > >Greetings, > >I noticed a (harmless) bounds warning triggered by the reduction in size >of array->bitmap. Patchlet below. > > -Mike I just checked my logs, and it appears my workload didn't trigger this one Mike. And so far, v8 is working great here. And that great is in my best "Tony the Tiger" voice, stolen shamelessly from the breakfast cereal tv commercial of 30+ years ago. :) Ingo asked for a 0-100 rating, where 0 is mainline as I recall it, and 100 is the best of the breed. I'll give this one a 100 till something better shows up. > CC kernel/sched.o >kernel/sched_rt.c: In function �load_balance_start_rt�: >include/asm-generic/bitops/sched.h:30: warning: array subscript is above > array bounds kernel/sched_rt.c: In function �pick_next_task_rt�: >include/asm-generic/bitops/sched.h:30: warning: array subscript is above > array bounds > >--- linux-2.6.21-cfs.v8/include/asm-generic/bitops/sched.h.org 2007-05-02 > 07:16:47.000000000 +0200 +++ > linux-2.6.21-cfs.v8/include/asm-generic/bitops/sched.h 2007-05-02 > 07:20:45.000000000 +0200 @@ -6,28 +6,23 @@ > > /* > * Every architecture must define this function. It's the fastest >- * way of searching a 140-bit bitmap where the first 100 bits are >- * unlikely to be set. It's guaranteed that at least one of the 140 >- * bits is cleared. >+ * way of searching a 100-bit bitmap. It's guaranteed that at least >+ * one of the 100 bits is cleared. > */ > static inline int sched_find_first_bit(const unsigned long *b) > { > #if BITS_PER_LONG == 64 >- if (unlikely(b[0])) >+ if (b[0]) > return __ffs(b[0]); >- if (likely(b[1])) >- return __ffs(b[1]) + 64; >- return __ffs(b[2]) + 128; >+ return __ffs(b[1]) + 64; > #elif BITS_PER_LONG == 32 >- if (unlikely(b[0])) >+ if (b[0]) > return __ffs(b[0]); >- if (unlikely(b[1])) >+ if (b[1]) > return __ffs(b[1]) + 32; >- if (unlikely(b[2])) >+ if (b[2]) > return __ffs(b[2]) + 64; >- if (b[3]) >- return __ffs(b[3]) + 96; >- return __ffs(b[4]) + 128; >+ return __ffs(b[3]) + 96; > #else > #error BITS_PER_LONG not defined > #endif -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) I met my latest girl friend in a department store. She was looking at clothes, and I was putting Slinkys on the escalators. -- Steven Wright - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 2 May 2007 04:20 * Gene Heskett <gene.heskett(a)gmail.com> wrote: > > I noticed a (harmless) bounds warning triggered by the reduction in > > size of array->bitmap. Patchlet below. > > I just checked my logs, and it appears my workload didn't trigger this > one Mike. [...] yeah: this is a build-time warning and it needs a newer/smarter gcc to notice that provably redundant piece of code. It's a harmless thing - but nevertheless Mike's fix is a nice little micro-optimization as well: it always bothered me a bit that at 140 priority levels we were _just_ past the 128 bits boundary by 12 bits. Now on 64-bit boxes it's just two 64-bit words to cover all 100 priority levels of RT tasks. > [...] And so far, v8 is working great here. And that great is in my > best "Tony the Tiger" voice, stolen shamelessly from the breakfast > cereal tv commercial of 30+ years ago. :) heh :-) > Ingo asked for a 0-100 rating, where 0 is mainline as I recall it, and > 100 is the best of the breed. I'll give this one a 100 till something > better shows up. nice - and you arent even using any OpenGL games ;) The 0-100 rating is really useful to me so that i can see the impact of regressions (if any) and it's also one single number representing the subjective impression - that way it's easier to keep tab of things. btw., do you still renice kmail slightly, or does it now work out of box with default nice 0? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Gene Heskett on 2 May 2007 04:20 On Wednesday 02 May 2007, Mike Galbraith wrote: >On Tue, 2007-05-01 at 23:22 +0200, Ingo Molnar wrote: >> - interactivity: precise load calculation and load smoothing > >This seems to help quite a bit. > >(5 second top sample) > > 2636 root 15 -5 19148 15m 5324 R 73 1.5 1:42.29 0 > amarok_libvisua 5440 root 20 0 320m 36m 8388 S 18 3.6 3:28.55 > 1 Xorg 4621 root 20 0 22776 18m 4168 R 12 1.8 0:00.63 1 cc1 > 4616 root 20 0 19456 13m 2200 R 9 1.3 0:00.43 0 cc1 > >I no longer have to renice both X and Gforce to achieve a perfect >display when they are sharing my box with a make -j2. X is displaying >everything it's being fed beautifully with no help. I have to renice >Gforce (amarok_libvisual), but given it's very heavy CPU usage, that >seems perfectly fine. > >No regressions noticed so far. Box is _very_ responsive under load, >seemingly even more so than with previous releases. That is purely >subjective, but the first impression was very distinct. > > -Mike And I have a make -j4 running to apply your patch Mike, and can't tell it from here, no lag. This is another keeper folks. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) It takes less time to do a thing right than it does to explain why you did it wrong. -- H.W. Longfellow - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mike Galbraith on 2 May 2007 04:20
On Wed, 2007-05-02 at 04:03 -0400, Gene Heskett wrote: > I just checked my logs, and it appears my workload didn't trigger this one > Mike. It's just a build time compiler warning. > Ingo asked for a 0-100 rating, where 0 is mainline as I recall it, and 100 is > the best of the breed. I'll give this one a 100 till something better shows > up. Ditto. (so far... ya never know;) -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |