From: Pavel Machek <pavel@ucw.cz>
To: Andrew Morton <akpm@osdl.org>
Cc: Nigel Cunningham <ncunningham@linuxmail.org>,
Stefan Seyfried <seife@suse.de>,
linux-kernel@vger.kernel.org, "Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Tue, 26 Sep 2006 00:45:00 +0200 [thread overview]
Message-ID: <20060925224500.GB2540@elf.ucw.cz> (raw)
In-Reply-To: <20060925144558.878c5374.akpm@osdl.org>
Hi!
On Mon 2006-09-25 14:45:58, Andrew Morton wrote:
> On Tue, 26 Sep 2006 07:34:03 +1000
> Nigel Cunningham <ncunningham@linuxmail.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
next prev parent reply other threads:[~2006-09-25 22:45 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-25 7:13 [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode") Stefan Seyfried
2006-09-25 8:12 ` Rafael J. Wysocki
2006-09-25 8:17 ` Pavel Machek
2006-09-25 19:02 ` Rafael J. Wysocki
2006-09-25 21:34 ` When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode")) Nigel Cunningham
2006-09-25 21:45 ` Andrew Morton
2006-09-25 22:45 ` Pavel Machek [this message]
2006-09-25 23:06 ` Andrew Morton
2006-09-25 23:21 ` Pavel Machek
2006-09-26 0:22 ` Andrew Morton
2006-09-26 10:08 ` Stefan Seyfried
2006-09-26 10:24 ` Pavel Machek
2006-09-26 16:46 ` Andrew Morton
2006-09-27 9:09 ` Pavel Machek
2006-09-27 21:08 ` Andrew Morton
2006-09-27 21:13 ` Rafael J. Wysocki
2006-09-27 21:34 ` Pavel Machek
2006-09-27 22:58 ` Andrew Morton
2006-09-27 23:18 ` Pavel Machek
2006-09-26 19:46 ` Rafael J. Wysocki
2006-09-26 16:45 ` Bryan O'Sullivan
2006-09-26 17:44 ` Alan Cox
2006-09-26 17:29 ` Bryan O'Sullivan
2006-09-27 9:09 ` Pavel Machek
2006-09-26 19:56 ` Rafael J. Wysocki
2006-09-26 20:14 ` Adrian Bunk
2006-09-26 20:35 ` Rafael J. Wysocki
2006-09-26 21:38 ` Nigel Cunningham
2006-09-26 22:31 ` Adrian Bunk
2006-09-26 22:51 ` Rafael J. Wysocki
2006-09-26 23:05 ` Nigel Cunningham
2006-09-26 23:31 ` Rafael J. Wysocki
2006-09-26 23:39 ` Adrian Bunk
2006-09-27 0:16 ` Andrew Morton
2006-09-27 5:12 ` Rafael J. Wysocki
2006-09-27 5:39 ` Nigel Cunningham
2006-09-27 6:00 ` Andrew Morton
2006-09-27 7:47 ` Rafael J. Wysocki
2006-09-27 8:58 ` Pavel Machek
2006-09-27 9:02 ` Pavel Machek
2006-09-27 23:21 ` Adrian Bunk
2006-09-28 10:59 ` Rafael J. Wysocki
2006-09-26 23:43 ` Nigel Cunningham
2006-09-25 22:34 ` Pavel Machek
2006-09-26 10:12 ` Stefan Seyfried
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060925224500.GB2540@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ncunningham@linuxmail.org \
--cc=rjw@sisk.pl \
--cc=seife@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®