swsusp2 and smp
Posted Dec 2, 2004 7:56 UTC (Thu) by
Duncan (guest, #6647)
Parent article:
Merging swsusp2
I'm still waiting for software suspend that
actually works on SMP (and
amd64 smp at that). I've been told swsusp2 does, but haven't wished to go
adding a patch set like that to my otherwise basically vanilla kernel.
Thus, I'm really interested in seeing swsusp2 merged.
Presently, I can disable ACPI and use APM hardware suspend (to ram), and
that's what I've been doing lately. The problem there is things like ntpd
which don't know they are suspended. I end up having to stop ntpd, then
restart ntp-client and ntpd after awakening. It'd sure be nice to have
all that handled automatically, with acpi enabled.
The other possibility, of course, is that of using the evolving CPU
hotplug technology to handle both suspend, and CPU speed throttling (which
also doesn't work on smp) as well. The idea, once CPU hotplugging is
sufficiently mature, would be to use its process migration features to
turn off one CPU at a time until only the primary CPU remains, at which
point the system could treat it like a single CPU system and trottle or
suspend it accordingly. Of course, in addition to the other complexities
of such a solution, consider NUMA architectures and the entirely possible
scenario where the memory accessible to a single CPU won't hold the entire
running system. We then end up having to swap what won't fit to
disk, /then/ do the throttling or suspending of what remains. If it's not
handled carefully, that's begging for a swap storm and some unfortunately
long time-to-single-cpu while headed to throttling mode or suspend. For
suspend that might be acceptable, but if it takes 30 seconds to turn on or
off the second CPU on the way to what's supposed to be transparent
throttling mode, it's not going to be acceptable.
Anyway, mature CPU hotplugging seems to be some time off in the first
place, and beyond that it'd have to be adopted for this, so swsusp2 would
appear to be a quicker solution. I'd love to have it in the kernel to
play with, particularly if it DOES handle multiple CPUs.
BTW, anyone know how multi-core CPUs will be handled in this regard? One
would /think/ the hardware at least would be able to handle that without
the race conditions in the multi-socket solution. Will the kernel and
necessary userspace handle it as well, or will it see it as two physically
separate CPUs and refuse to handle them with "conventional" throttling and
suspend mechanisms?
Duncan
(
Log in to post comments)
