On Wed, 2006-04-19 at 12:59 +1000, Nigel Cunningham wrote:
> 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.
Sounds like a good idea. If NVS is already aligned to page size, do you
still use the pseudo driver to save/restore the pages? In my system, the
NVS memory is 512k.
In the other way, we could let the 'swsusp_add_arch_pages' accept
address instead of a pfn and let snapshot.c handle the partial page
issue.
> 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?).
Yes, we can get the amount of memory needed ahead per the e820 map.
Thanks,
Shaohua
-
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]
