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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Sep 2006 00:45:00 +0200
From:	Pavel Machek <pavel@....cz>
To:	Andrew Morton <akpm@...l.org>
Cc:	Nigel Cunningham <ncunningham@...uxmail.org>,
	Stefan Seyfried <seife@...e.de>, linux-kernel@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))

Hi!

On Mon 2006-09-25 14:45:58, Andrew Morton wrote:
> On Tue, 26 Sep 2006 07:34:03 +1000
> Nigel Cunningham <ncunningham@...uxmail.org> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/