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: Srivatsa Vaddagiri on 7 May 2007 10:20 On Thu, May 03, 2007 at 08:53:47AM -0700, William Lee Irwin III wrote: > On Thu, May 03, 2007 at 08:23:18PM +0530, Srivatsa Vaddagiri wrote: > > And what about group scheduling extensions? Do you have plans to work on > > it? I was begining to work on a prototype to do group scheduling based > > on CFS, basically on the lines of what you and Linus had outlined > > earlier: > > http://lkml.org/lkml/2007/4/18/271 > > http://lkml.org/lkml/2007/4/18/244 > > Tong Li's Trio scheduler does a bit of this, though it doesn't seem to > have the mindshare cfs seems to have acquired. > > The hyperlink seems to have broken, though: > http://www.cs.duke.edu/~tongli/linux/linux-2.6.19.2-trio.patch The big question I have is, how well does DWRR fits into the "currently hot" scheduling frameworks like CFS? For ex: if the goal is to do fair (group) scheduling of SCHED_NORMAL tasks, can CFS and DWRR co-exist? Both seem to be radically different algorithms and my initial impressions of them co-existing is "No", but would be glad to be corrected if I am wrong. If they can't co-exist, then we need a different way of doing group scheduling on top of CFS, as that is gaining more popularity on account of better handling of interactivity. Tong, I understand a center hallmark of DWRR is SMP fairness. Have you considered how bad/good the other alternative to achieve SMP fairness which is in vogue today : pressure/weight based balancing (ex: smpnice and CKRM CPU scheduler - ckrm.sourceforge.net/downloads/ckrm-ols03-slides.pdf)? -- Regards, vatsa - 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 7 May 2007 12:10 * Esben Nielsen <nielsen.esben(a)googlemail.com> wrote: > I would hate to tell mission control for Mankind's first mission to > another star to reboot every 200 years because "there is no need to > worry about it." ok, i need no other argument - fixed :-) (btw., if anyone from the planning committee of Mankind's first mission to another star has any other particular wish about CFS's design, i'm all ears and it's going to get the highest possible priority!) i really mean it! (And i guess you discovered my weak spot. Darn :) Hopefully they wont ask for STREAMS support, that would put us into a _really_ difficult position.) 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: Linus Torvalds on 7 May 2007 12:20 On Mon, 7 May 2007, Esben Nielsen wrote: > > I would hate to tell mission control for Mankind's first mission to another > star to reboot every 200 years because "there is no need to worry about it." I'd like to put it another way: - if your mission to another star *depends* on every single piece of complex equipment staying up with zero reboots for 200+ years, you have some serious technology problems. In other words: your argument is populist, and totally silly. Trust me, if you are going to another star, you'd better have the capabilities to handle bugs. You'd better have multiple fail-over etc. A notion of "robustness" cannot and must not hinge on "no bugs". That's unrealistic. > As a matter of principle an OS should never need a reboot (with exception for > upgrading). If you say you have to reboot every 200 years, why not every 100? > Every 50? .... Every 45 days (you know what I am referring to :-) ? There's something of a difference between 45 days and 292 years. I'm not saying we can't get there, but worrying about it in the current state is just stupid. It's not just looking at the trees and not seeing the forest, it's looking at one *leaf*, and missing the forest. And quite frankly, if you work for NASA and are aiming for the stars, you'd better not be that person who looks at one leaf and cannot see the forest around you. That's the kind of thing that makes you miss the difference between miles and kilometers. Linus - 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: Linus Torvalds on 7 May 2007 12:40 On Mon, 7 May 2007, Esben Nielsen wrote: > > What is (long)(a-b) ? I have tried to look it up in the C99 standeard but I > can't find it. Maybe it is in the referred LIA-1 standeard, which I can't find > with google. I don't worry about non-2's-complement machines (they don't exist, and likely won't exist in the future either). So I worry about compilers rewriting my code. So "(long)(a-b) < 0" (with "a" and "b" being unsigned long) is basically a portable way of testing the high bit of the result. > I think the best would be to use "a-b > ULONG_MAX/2" when you mean "a<b" as > that should be completely portable. That certainly works too, but the difference is irrelevant, since Linux is unlikely to work on insane machines anyway (ie we do make a lot of other assumptions about the architecture, being two's-complement is the least of those). So you basically shouldn't worry about hardware: everybody is pretty much the same. You should worry about *compilers* - that's where the differences show up. So "(long)(a-b)" may be "implementation defined" (but since implementations are all 2's complement, we don't care), but a signed "(a-b)" that over/overflows is *undefined*, and that is much worse because it means that the compiler can do some funky stuff, and _that_ is a real practical worry. And no, I also don't worry about porting Linux to 18-bit machines, or to ternary CPU's. Linus - 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: Johannes Stezenbach on 7 May 2007 14:50
On Mon, May 07, 2007, Linus Torvalds wrote: > On Mon, 7 May 2007, Esben Nielsen wrote: > > > > What is (long)(a-b) ? I have tried to look it up in the C99 standeard but I > > can't find it. Maybe it is in the referred LIA-1 standeard, which I can't find > > with google. C99 defines unsigned overflow semantics, but it doesn't say anything about signed overflow, thus it's undefined -- and you have a hard time finding it out. However, I have no clue *why* it's undefined and not implementation defined. Does someone know? > I don't worry about non-2's-complement machines (they don't exist, and > likely won't exist in the future either). I think DSPs can do saturated arithmetics (clamp to min/max values instead of wrap around). Not that it matters for Linux... > So I worry about compilers rewriting my code. gcc has -fwrapv and -ftrapv to change signed integer overflow behaviour. One baffling example where gcc rewrites code is when conditionals depend on signed integer overflow: $ cat xx.c #include <assert.h> int foo(int a) { assert(a + 100 > a); return a; } int bar(int a) { if (a + 100 > a) a += 100; return a; } $ gcc -Wall -Wextra -fomit-frame-pointer -c xx.c $ objdump -dr xx.o xx.o: file format elf32-i386 Disassembly of section .text: 00000000 <foo>: 0: 8b 44 24 04 mov 0x4(%esp),%eax 4: c3 ret 00000005 <bar>: 5: 83 44 24 04 64 addl $0x64,0x4(%esp) a: 8b 44 24 04 mov 0x4(%esp),%eax e: c3 ret The assert and the condition were just dropped by gcc -- without any warning. gcc-4.2 will add -fstrict-overflow and -Wstrict-overflow. http://gcc.gnu.org/gcc-4.2/changes.html Johannes - 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/ |