[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45F86B56.6020606@goop.org>
Date: Wed, 14 Mar 2007 14:38:30 -0700
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: Con Kolivas <kernel@...ivas.org>
CC: Andi Kleen <ak@...e.de>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Rusty Russell <rusty@...tcorp.com.au>,
Zachary Amsden <zach@...are.com>,
James Morris <jmorris@...ei.org>,
john stultz <johnstul@...ibm.com>,
Chris Wright <chrisw@...s-sol.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
cpufreq@...ts.linux.org.uk,
Virtualization Mailing List <virtualization@...ts.osdl.org>
Subject: Re: Stolen and degraded time and schedulers
Con Kolivas wrote:
> I think you're looking for a complex solution to a problem that doesn't exist.
>
The problem is subtle, but I think the solution is actually fairly simple.
> The job of the process scheduler is to meter out the available cpu resources.
> It cannot make up cycles for a slow cpu or one that is throttled.
No, it can't schedule more cpu time than exists. But it should account
for the time the processes actually had available to them, rather than
assuming they got the full power of the cpu.
> If the
> problem is happening due to throttling it should be fixed by altering the
> throttle. The example you describe with the conservative governor is as easy
> to fix as changing to the ondemand governor.
That's one workaround, but sometimes its desirable to keep even
cpu-bound processes at a lower cpu performance level for power-saving
reasons. Modern CPUs are designed to switch performance states very
quickly, so its conceivable you could change performance every context
switch, though no governor currently uses that fine granularity.
> Differential power cpus on an
> SMP machine should be managed by SMP balancing choices based on power groups.
>
Do you mean compute power or energy power here?
> It would be fine to implement some other accounting of this definition of time
> for other purposes but not for process scheduler decisions per se.
>
I suppose, but it seems to me that they're pretty much the same thing.
> Sorry to chime in late. My physical condition prevents me spending any
> extended period of time at the computer so I've tried to be succinct with my
> comments and may not be able to reply again.
>
My sympathies; neck problems are bad news.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists