From: Pavel Machek <pavel@ucw.cz>
To: Nigel Cunningham <ncunningham@linuxmail.org>
Cc: Andrew Morton <akpm@digeo.com>,
Patrick Mochel <mochel@digitalimplant.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Suspend2 Merge: Driver model patches 0/2
Date: Thu, 16 Sep 2004 14:13:00 +0200 [thread overview]
Message-ID: <20040916121259.GA3125@elf.ucw.cz> (raw)
In-Reply-To: <1095335274.4932.219.camel@laptop.cunninghams>
Hi!
> > > do it later:
> > >
> > > Suspend all other drivers.
> > > Write pageset 2 (page cache).
> > > Suspend used drivers.
> > > Make atomic copy.
> > > Resume used drivers.
> > > Write pageset 1 (atomic copy)
> > > Suspend used drivers.
> > > Power down all.
> >
> > What is problem with:
> >
> > Write pageset 2
> > Suspend all drivers (avoiding slow operations)
> > Make atomic copy
> > Resume all drivers (avoiding slow operations)
> > Write pageset 1
> > Suspend all drivers
> > Power down all.
>
> It's always interesting trying to remember your logic for doing
> something after the fact :>. If I recall correctly, it goes like this:
>
> Writing two pagesets forces me to account for memory usage much more
> carefully. I need to ensure before I start to write the image that I
> know exactly what the size is and have allocated enough memory to do the
> write. If I get some driver coming along and grabbing memory for who
> knows what (hotplug, anyone? :>), I may get stuck halfway through
> writing the image with no memory to use. I also have to be paranoid
> about how much memory is available because I save that too (some of it
> may have become slab by the time I do the atomic copy).
What prevents video driver or disk driver to grab some memory? Tree
containing disk device can be pretty big [pci-usb-usb_hub-disk] and
contain some hot-pluggable components.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
next prev parent reply other threads:[~2004-09-16 12:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-16 10:58 [PATCH] Suspend2 Merge: Driver model patches 0/2 Nigel Cunningham
2004-09-16 11:18 ` Pavel Machek
2004-09-16 11:29 ` Nigel Cunningham
2004-09-16 11:32 ` Pavel Machek
2004-09-16 11:47 ` Nigel Cunningham
2004-09-16 12:13 ` Pavel Machek [this message]
2004-09-16 22:06 ` Nigel Cunningham
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=20040916121259.GA3125@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
--cc=ncunningham@linuxmail.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.