Hi!
On Mon 2006-09-25 14:45:58, Andrew Morton wrote:
> On Tue, 26 Sep 2006 07:34:03 +1000
> Nigel Cunningham <[email protected]> wrote:
>
> > </rant>
>
> metoo! I'd suggest that it'd be better to be expending the grey cells on
> making the present suspend stuff nice and solid, stable and fast.
[Un?]fortunately, Novell has some suggestions how I should expend my
grey cells in this area.
Anyway you want:
nice)
not sure if me + Rafael can do much here. Perhaps someone else
has to go through the code and rewrite it one more time? Or do
you have specific areas where suspend is really ugly?
solid)
apart from HIGHMEM64G fiasco, and related agpgart fiasco long
time before that... these are driver problems...
stable)
I believe we are doing pretty well in this area. We did not
have too many regressions, did we? (And notice that nice+fast
are actually both conflicting goals with stable).
fast)
frankly, that is not my priority for in-kernel
suspend. uswsusp will always be few seconds faster, thanks to
LZW. If we do 40MB/sec or 50MB/sec during write is not that
important. Patches are always welcome.
> I mean, right now a suspend-to-disk spends more time futzing around doing
> mysterious-but-probably-pointless stuff than it does writing memory to
> disk. I've no idea what it's doing with all that time, but I'll wager it's
> not very useful to anyone ;)
I liked the previous description more ;-).
Anyways this boils down to "find which drivers are delaying suspend
and fix them".
Okay, we could:
* avoid sending drivers down/up/down again during suspend... but that
will be ugly tree manipulating code, and all devices doing DMA must be
down, anyway... so it is probably easier to do it on per-driver basis
(as is done now) than in generic code
* tweak memory copying loops to make them slighty faster. But as
memory speeds are in GB/sec ranges, I'm not sure it is worth
optimizing.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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]
