Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))

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

 



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]
  Powered by Linux