On Tuesday 08 June 2010, Nigel Cunningham wrote: > Hi Rafael. > > On 07/06/10 18:49, Rafael J. Wysocki wrote: > > On Monday 07 June 2010, Nigel Cunningham wrote: > >> On 07/06/10 05:04, Rafael J. Wysocki wrote: > >>> On Sunday 06 June 2010, Maxim Levitsky wrote: > >>>> On Sun, 2010-06-06 at 15:57 +0200, Rafael J. Wysocki wrote: > >>>>> On Sunday 06 June 2010, Maxim Levitsky wrote: > >>>>> So how TuxOnIce helps here? > >>>> Very simple. > >>>> > >>>> With swsusp, I can save 750MB (memory) + 250 Vram (vram) > >>>> With full memory save I can save (1750 MB of memory) + 250 MB of > >>>> vram.... > >>> > >>> So what about being able to save 1600 MB total instead of the 2 GB > >>> (which is what we're talking about in case that's not clear)? Would it > >>> be _that_ _much_ worse? > >> > >> That all depends on what is in the 400MB you discard. > > > > Well, they are discarded following the LRU algorithm and it's very much > > like loading a program that takes 20% of your memory upfront. > > > >> The difference is "Just as if you'd never hibernated" vs something > >> closer to "Just as if you'd only just started up". We can't make > >> categorical statements because it really does depend upon what you > >> discard and what you want to do post-resume - that is, how useful the > >> memory you discard would have been. That's always going to vary from > >> case to case. > > > > Not so much. > > > > Besides, it doesn't matter too much. > > > > Let me reiterate, please. Doing serious memory management behind the back > > of the mm subsystem (and trying to do that so it doesn't notice) is wrong and > > the reason it works is by accident. As long as you do that, I have a problem > > with TuxOnIce. > > I know we're at a point where it doesn't matter what I say - you've made > up you're mind and are not going to be persuaded by anything I say. > We're degenerating from a technical discussion into emotive language. > > This is why I object to the way you're picturing things. TuxOnIce isn't > doing "serious memory management behind the back of the mm subsystem" or > working "by accident". It's an algorithm that has been designed to rely > on and use both the freezer and the existing mm subsystem to provide a > means wherein we can get more reliable hibernation and a fuller image of > memory. > > May I suggest that we seek to get away from this point and focus on what > we can agree on. Sure. > Do you have any object to my work in the areas of: > > - speed (async I/O, multithreaded I/O) > - flexibility (support for multiple swap devices, support for non swap, > UUID support) > - tuneability (sysfs interface) > - anything else I might have forgotten to mention No, that's all fine, perhaps up to some details, but fundamentally I don't have a problem with that. Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
