From: Nigel Cunningham <ncunningham@cyclades.com>
To: Shaohua Li <shaohua.li@intel.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>, Pavel Machek <pavel@ucw.cz>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH 2/3] swsusp i386 mark special saveable/unsaveable pages
Date: Wed, 19 Apr 2006 12:59:53 +1000 [thread overview]
Message-ID: <200604191259.57951.ncunningham@cyclades.com> (raw)
In-Reply-To: <1145415212.19994.15.camel@sli10-desk.sh.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1505 bytes --]
Hi.
On Wednesday 19 April 2006 12:53, Shaohua Li wrote:
> On Wed, 2006-04-19 at 12:08 +1000, Nigel Cunningham wrote:
> > Hi.
> >
> > On Wednesday 19 April 2006 11:51, Shaohua Li wrote:
> > > On Wed, 2006-04-19 at 11:41 +1000, Nigel Cunningham wrote:
> > > > Oh, and while we're on the topic, if only part of a page is NVS,
> > > > what's the right behaviour? My e820 table has:
> > > >
> > > > BIOS-e820: 000000003dff0000 - 000000003dffffc0 (ACPI data)
> > > > BIOS-e820: 000000003dffffc0 - 000000003e000000 (ACPI NVS)
> > >
> > > If only part of a page is NVS, my patch will save the whole page. Any
> > > other idea?
> >
> > A device model driver that handles saving just the part of the page,
> > using preallocated buffers to avoid the potential allocation problems?
> > (The whole page could then safely be Nosave).
>
> The allocation might not be a problem, this just needs one or two extra
> pages. A problem is if just part of the page is NVS, could we touch
> other part (save/restore) the page.
Yes, so I was thinking of treating it with a pseudo driver that could save and
restore just that portion of the page.
Regarding the allocation, I was originally thinking of that other ACPI
allocation while atomic issue, and trying to avoid another one. I guess this
is simpler though because we know ahead of time how much is needed (am I
right in thinking that in the other case, the amount of memory needed isn't
known ahead of time?).
Regards,
Nigel
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2006-04-19 3:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-12 2:38 [PATCH 2/3] swsusp i386 mark special saveable/unsaveable pages Shaohua Li
2006-04-18 22:38 ` Nigel Cunningham
2006-04-19 1:22 ` Shaohua Li
2006-04-19 1:41 ` Nigel Cunningham
2006-04-19 1:51 ` Shaohua Li
2006-04-19 2:08 ` Nigel Cunningham
2006-04-19 2:53 ` Shaohua Li
2006-04-19 2:59 ` Nigel Cunningham [this message]
2006-04-19 3:28 ` Shaohua Li
2006-04-19 6:33 ` Nigel Cunningham
2006-04-20 3:08 ` Shaohua Li
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=200604191259.57951.ncunningham@cyclades.com \
--to=ncunningham@cyclades.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
--cc=shaohua.li@intel.com \
/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.