Re: [RFC] (How to) Let idle CPUs sleep

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Srivatsa Vaddagiri wrote:
On Fri, May 13, 2005 at 08:29:17AM +0000, Nick Piggin wrote:

And don't forget that the watchdog approach can just as easily deep
sleep a CPU only to immediately wake it up again if it detects an
imbalance.


I think we should increase the threshold beyond which the idle CPU
is woken up (more than the imbalance_pct that exists already). This
should justify waking up the CPU.


Oh yeah that's possible (and maybe preferable - testing will need to
be done). But again it doesn't solve the corner cases where problems
happen. And it introduces more divergence to the balancing algorithms.

Basically I'm trying to counter the notion that the watchdog solution
is fundamentally better just because it allows indefinite sleeping and
backoff doesn't. You'll always be waking things up when they should
stay sleeping, and putting them to sleep only to require they be woken
up again.


And the CPU usage / wakeup cost arguments cut both ways. The busy
CPUs have to do extra work in the watchdog case.


Maybe with a really smart watchdog solution, we can cut down this overhead.

Really smart usually == bad, especially when it's not something that
has been shown to be terribly critical.

I did think of other schemes - a dedicated CPU per node acting as watchdog for that node and per-node wacthdog kernel threads? - to name a few. What I had proposed was the best I thought. But maybe we can look at improving it to see if the overhead concern you have can be reduced - meeting the interests
of both the worlds :)

My main concern is complexity, second concern is diminishing returns,
third concern is overhead on other CPUs :)

But I won't pretend to know it all - I don't have a good grasp of the
problem domains, so I'm just making some noise now so we don't put in
a complex solution where a simple one would suffice.

The best idea obviously would be to get the interested parties involved,
and get different approaches running side by side, then measure things!


-
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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux