On 4/17/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
The ongoing scheduler work is on a much more basic level than these affairs I'm guessing you googled. When the basics work as intended it will be possible to move on to more advanced issues.
OK, let me try this in smaller words for people who can't tell bitter experience from Google hits. CPU clock scaling for power efficiency is already the only thing that matters about the Linux scheduler in my world, because battery-powered device vendors in their infinite wisdom are abandoning real RTOSes in favor of Linux now that WiFi is the "in" thing (again). And on the timescale that anyone will actually be _using_ this shiny new scheduler of Ingo's, it'll be nearly the only thing that matters about the Linux scheduler in anyone's world, because the amount of work the CPU can get done in a given minute will depend mostly on how intelligently it can spend its heat dissipation budget. Clock scaling schemes that aren't integral to the scheduler design make a bad situation (scheduling embedded loads with shotgun heuristics tuned for desktop CPUs) worse, because the opaque heuristics are now being applied to distorted data. Add a "smoothing" scheme for the distorted data, and you may find that you have introduced an actual control-path instability. A small fluctuation in the data (say, two bursts of interrupt traffic at just the right interval) can result in a long-lasting oscillation in some task's "dynamic priority" -- and, on a fully loaded CPU, in the time that task actually gets. If anything else depends on how much work this task gets done each time around, the oscillation can easily propagate throughout the system. Thrash city. (If you haven't seen this happen on real production systems under what shouldn't be a pathological load, you haven't been around long. The classic mechanisms that triggered oscillations in, say, early SMP Solaris boxes haven't bitten recently, perhaps because most modern CPUs don't lose their marbles so comprehensively on context switch. But I got to live this nightmare again recently on ARM Linux, due to some impressively broken application-level threading/locking "design", whose assumptions about scheduler behavior got broken when I switched to an NPTL toolchain.) I don't have the training to design a scheduler that isn't vulnerable to control-feedback oscillations. Neither do you, if you haven't taken (and excelled at) a control theory course, which nowadays seems to be taught by applied math and ECE departments and too often skipped by CS types. But I can recognize an impending train wreck when I see it. Cheers, - Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/