Re: [PATCH 0/6 v2] PM / Hibernate: Memory bitmap scalability improvements

From: Rafael J. Wysocki
Date: Mon Jul 21 2014 - 20:23:16 EST


On Tuesday, July 22, 2014 01:05:00 AM Pavel Machek wrote:
> Hi!
>
> On Mon 2014-07-21 18:03:46, Joerg Roedel wrote:
> > On Mon, Jul 21, 2014 at 04:10:27PM +0200, Pavel Machek wrote:
> > > > And Linux is only made for sane people? Thats pretty new to me ;-)
> > >
> > > Yeah, but please don't optimize for insane people :-).
> >
> > Thats rather discriminating, even more when you realize that 'insane' is
> > a very subjective attribute.
>
> You admitted you don't even have access to machine you are trying to
> optimize for.
>
> > > #6 is bugfix. We should take it. Rest is performance improvement for
> > > insane config. I don't think we should take it.
> >
> > Have you any other reason against these changes besides your
> > proven-to-be-wrong disbelief that it is necessary?
>
> Where you proven me wrong?
>
> If kernel is preparing bitmaps before checking resume signature, that
> is bug that costs you 60 seconds boot time on your 12TB machine. Fix
> that bug. It will benefit everyone.
>
> Software watchdog during hibernation on 12TB machine is a bug that
> hits insane people. Ok, lets fix it.
>
> Optimizing hibernation for memory-is-empty case is wrong. Linux tries
> to use as much memory as it can.
>
> Hibernating 12TB machine will take 5 hours or more. Redoing data
> structures to save 60 seconds of 5 hour process is not worth
> it. Nobody sane would hibernate 12TB machine.

It looks like some specific need motivated the Joerg's work, however,
so let's just not dismiss the use case lightly without knowing it.

That said I would like to know how much time we save through this
optimization relative to the total hibernation time on systems with
various amounts of memory (say, 4 GB, 8 GB, 16 GB, 32 GB, more) and
whether or not it makes hibernation slower in any case.

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/