[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <201006081101.30993.rjw@sisk.pl>
Date: Tue, 8 Jun 2010 11:01:30 +0200
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Nigel Cunningham <ncunningham@...a.org.au>
Cc: LKML <linux-kernel@...r.kernel.org>,
pm list <linux-pm@...ts.linux-foundation.org>,
"TuxOnIce-devel" <tuxonice-devel@...onice.net>
Subject: Re: [linux-pm] [SUSPECTED SPAM] Re: Proposal for a new algorithm for reading & writing a hibernation image.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists