Proposal for a new algorithm for reading & writing a hibernation image.
in [Kernel]
|
Prev: early_res: fix check in free_early_partial
Next: 2.6.35-rc1 system oom, many processes killed but memory not free
From: Nigel Cunningham on 4 Jun 2010 20:30 Hi again. As I think about this more, I reckon we could run into problems at resume time with reloading the image. Even if some bits aren't modified as we're writing the image, they still might need to be atomically restored. If we make the atomic restore part too small, we might not be able to do that. So perhaps the best thing would be to stick with the way TuxOnIce splits the image at the moment (page cache / process pages vs 'rest'), but using this faulting mechanism to ensure we do get all the pages that are changed while writing the first part of the image. Regards, Nigel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Maxim Levitsky on 5 Jun 2010 15:20
On Sat, 2010-06-05 at 20:45 +0200, Rafael J. Wysocki wrote: > On Saturday 05 June 2010, Nigel Cunningham wrote: > > Hi again. > > > > As I think about this more, I reckon we could run into problems at > > resume time with reloading the image. Even if some bits aren't modified > > as we're writing the image, they still might need to be atomically > > restored. If we make the atomic restore part too small, we might not be > > able to do that. > > > > So perhaps the best thing would be to stick with the way TuxOnIce splits > > the image at the moment (page cache / process pages vs 'rest'), but > > using this faulting mechanism to ensure we do get all the pages that are > > changed while writing the first part of the image. > > I still don't quite understand why you insist on saving the page cache data > upfront and re-using the memory occupied by them for another purpose. If you > dropped that requirement, I'd really have much less of a problem with the > TuxOnIce's approach. Because its the biggest advantage? Really saving whole memory makes huge difference. Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |