![]() | |||||||||||||
Messages in this thread |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-09-26 20:34 [from the cache] ©2003-2008 | |||||||||||||