I do agree that we might decide to just not do this at all except for the
actual physical bootup phase (which can use early_text_poke()). There may
not be a whole lot of point to ever play with smp_alterinatives() at any
other time.
Our device suspend right now takes about 3.5 seconds (that's using the
debug thing, which adds a 5-second timeout). That *is* a problem, but it's
historically been hidden by the fact that people are happy that suspend
works at all when it does.
These days, we're getting to the point (I think) that a lot more people
are going to take suspend for granted. And I'd actually like to use it as
a sleep state for desktop like usage (let's face it, when the screen goes
dark, the CPU should just go into suspend too if it's used as a desktop by
non-technical users).
And for that to be useful, it needs to come up quickly. Not add another
second on top of the already-irritating delay of the screen waking up.
Are we there yet? Hell no. But I don't think we're too far off.
Linus
--
