linux-kernel - Re: [RFC][PATCH 6/6] PM/Hibernate: Do not try to allocate too much memory too hard

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200905151640.01954.rjw@sisk.pl>
Date:	Fri, 15 May 2009 16:40:01 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Pavel Machek <pavel@....cz>
Cc:	pm list <linux-pm@...ts.linux-foundation.org>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Nigel Cunningham <nigel@...onice.net>,
	David Rientjes <rientjes@...gle.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [RFC][PATCH 6/6] PM/Hibernate: Do not try to allocate too much memory too hard

On Friday 15 May 2009, Pavel Machek wrote:
> Hi!
> 
> > > > We want to avoid attempting to free too much memory too hard during
> > > > hibernation, so estimate the minimum size of the image to use as the
> > > > lower limit for preallocating memory.
> > > 
> > > Why? Is freeing memory too slow?
> > > 
> > > It used to be that user controlled image size, so he was able to
> > > balance "time to save image" vs. "responsiveness of system after
> > > resume".
> > > 
> > > Does this just override user's preference when he chooses too small
> > > image size?
> > > 
> > > > The approach here is based on the (experimental) observation that we
> > > > can't free more page frames than the sum of:
> > > > 
> > > > * global_page_state(NR_SLAB_RECLAIMABLE)
> > > > * global_page_state(NR_ACTIVE_ANON)
> > > > * global_page_state(NR_INACTIVE_ANON)
> > > > * global_page_state(NR_ACTIVE_FILE)
> > > > * global_page_state(NR_INACTIVE_FILE)
> > > > 
> > > > and even that is usually impossible to free in practice, because some
> > > > of the pages reported as global_page_state(NR_SLAB_RECLAIMABLE) can't
> > > > in fact be freed.  It turns out, however, that if the sum of the
> > > > above numbers is subtracted from the number of saveable pages in the
> > > > system and the result is multiplied by 1.25, we get a suitable
> > > > estimate of the minimum size of the image.
> ...
> > > >  /**
> > > > + * minimum_image_size - Estimate the minimum acceptable size of an image
> > > > + * @saveable: The total number of saveable pages in the system.
> > > > + *
> > > > + * We want to avoid attempting to free too much memory too hard, so estimate the
> > > > + * minimum acceptable size of a hibernation image to use as the lower limit for
> > > > + * preallocating memory.
> > > 
> > > I don't get it. If user sets image size as 0, we should free as much
> > > memory as we can. I just don't see why "we want to avoid... it".
> > 
> > The "as much memory as we can" is not well defined.
> 
> Well, while (1) kmalloc(1024, GFP_KERNEL | GFP_NO_OOMKILL); is
> basically "as much memory as we can". I believe it is pretty well defined.
> 
> > Patches [4/6] and [5/6] make hibernation use memory allocations to force some
> > memory to be freed.  However, it is not really reasonable to try to allocate
> > until the allocation fails, because that stresses the memory management
> > subsystem too much.  It is better to predict when it fails and stop allocating
> > at that point, which is what the patch does.
> 
> Why is it wrong to stress memory management? It is a computer; it can
> handle it. Does it take too long?

Yes.

> Should the user just set image_size higher in such case?

Yes, he should.

> > The prediction is not very precise, but I think it need not be.  Even if it
> > leaves a few pages more in memory, that won't be a disaster.
> 
> Well, on 128MB machine, you'll fail suspend even if it would fit if
> code tried little harder...?

No.  Did you notice the min_t(unsigned long, pages, max_size) in the patch?
It's there exactly for this purpose (although I don't think it's really going
to trigger in practice). :-)

Thanks,
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/