Hi. On Sat, 2009-05-09 at 01:43 +0200, Rafael J. Wysocki wrote: > > On Sat, 2009-05-09 at 00:46 +0200, Rafael J. Wysocki wrote: > > > On Friday 08 May 2009, Nigel Cunningham wrote: > > > > On Fri, 2009-05-08 at 16:11 +0200, Rafael J. Wysocki wrote: > > > > > On Friday 08 May 2009, Nigel Cunningham wrote: > > > > And the code includes some fundamental differences. I freeze processes > > > > and prepare the whole image before saving anything or doing an atomic > > > > copy whereas you just free memory before doing the atomic copy. You save > > > > everything in one part whereas I save the image in two parts. > > > > > > IMO the differences are not that fundamental. The whole problem boils down > > > to using the same data structures for memory management and I think we can > > > reach an agreement here. > > > > I think we might be able to agree on using the same data structures, but > > I'm not so sure about algorithms - I think you're underestimating the > > differences here. > > Well, which algorithms do you have in mind in particular? Sorry for the slow reply - just starting to catch up after time away. The main difference is the order of doing things. TuxOnIce prepares the image after freezing processes and before the atomic copy. It doesn't just do that so that it can store a complete image of memory. It also does it because once processes are frozen, the only thing that's going to allocate storage is TuxOnIce, and the only things that are going to allocate RAM are TuxOnIce and the drivers' suspend routines. The drivers' routines are pretty consistent - once you've seen how much is used for one invocation, you can add a small margin and call that the allowance to use for all future invocations. The amount of memory used by the hibernation code is also entirely predictable - once you know the characteristics of the system as it stands (ie with processes frozen), you know how much you're going to need for the atomic copy and for doing I/O. If you find that something is too big, all you need to do is thaw kernel threads and free some memory until you fit within constraints or (heaven forbid!) find that you're not getting anyway and so want to give up on hibernating all together. If, on the other hand, you do the drivers suspend etc and then look to see what state you're in, well you might need to thaw drivers etc in order to free memory before trying again. It's more expensive. Right now you're just giving up in that case - yes, you could retry too instead of giving up completely, but it's better IMHO to seek to get things right before suspending drivers. Oh, before I forget to mention and you ask - how to know what allowance for the drivers? I use a sysfs entry - the user then just needs to see what's needed on their first attempt, set up a means of putting that value in the sysfs file in future (eg /etc/hibernate/tuxonice.conf) and then forget about it. Regards, Nigel _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
