Hi!
> > > > Lets see...
> > > >
> > > > for i386, we have 768 pagedir entries. Each pagedir entry points to
> > > > page with 1023 pointers to pages. That means that up-to 768*1023*4096
> > > > bytes image can be saved to swap ~= 768 * 1K * 4K ~= 3 GB. That's more
> > > > than enough for i386.
> > > >
> > > > for x86-64, we can have 128 pagedir entries (could not we fit more
> > > > there? 384 entries should fit, no?).
> > >
> > > Yes. To be exact, 460.
> > >
> > > > Each pagedir entry has 511 pointers to pages (IIRC)...
> > >
> > > 512, I think.
> >
> > Okay, can we do simple solution where we put 460 there, plus a check
> > if it overflows (printk, abort suspend), for now? That should fix
> > 768MB machine...
>
> For now: a constant in power.h depending on sizeof(long) and PAGE_SIZE,
> the size of swsusp_info.pagedir[] depending on it and the overflow check
> in write_pagedir()?
Yes, that would be very nice.
> Unfortunately it's not enough for what I'm cooking (think of resuming in 35 sec.
> to a fully responsive system - well, that's on my box). A preliminary patch
> is at http://www.sisk.pl/kernel/patches/2.6.14-rc2-git3/swsusp-improve-freeing-memory.patch
Okay, I see, nice... We want to support that in future. (Actually it
is last piece of puzzle for swsusp3).
> > No, they probably will not be consecutive.
> >
> > OTOH pagedirs are stored as a link list in memory already. Maybe we
> > should be able to extend that link list for a disk, too, with minimal
> > fuss? ...we'd have to write pagedir _backwards_ for that to work,
> > probably not nice, and swap_free() would really like direct access.
>
> We write the pagedir after we have written the image, so the address
> field of each entry is not needed at that time, except for freeing the
> image memory in case of failure (with the "rework image freeing patch"
> they are not needed at all). Thus potentially we can use the address
> fields of pagedir entries to link the pages on the swap.
I plan to push "rework image freeing patch" for other reasons,
too. I'd like to run longer tests on it, but so far it looks okay.
Pavel
--
if you have sharp zaurus hardware you don't need... you know my address
-
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]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |