From: Andrew Morton <akpm@digeo.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: Pavel Machek <pavel@ucw.cz>, kernel list <linux-kernel@vger.kernel.org>
Subject: Re: Good way to free as much memory as possible under 2.5.34?
Date: Fri, 13 Sep 2002 14:30:47 -0700 [thread overview]
Message-ID: <3D825907.493B4DB3@digeo.com> (raw)
In-Reply-To: Pine.LNX.4.44L.0209131808240.1857-100000@imladris.surriel.com
Rik van Riel wrote:
>
> On Fri, 13 Sep 2002, Pavel Machek wrote:
>
> > /*
> > * Try to free as much memory as possible, but do not OOM-kill anyone
> > *
> > * Notice: all userland should be stopped at this point, or livelock
> > is possible.
> > */
> >
> > This worked before -rmap came in, but it does not free anything
> > now. What needs to be done to fix it?
>
> Actually, it still worked when -rmap came in, but it stopped working
> when the LRU lists were made to be per-zone...
hmm, I missed that. Yes, the zone balancing in try_to_free_pages() will
see that all zones are above ->pages_high and will just return.
> > static void free_some_memory(void)
> > {
> > printk("Freeing memory: ");
> > while
> > (try_to_free_pages(&contig_page_data.node_zones[ZONE_HIGHMEM], GFP_KSWAPD, 0))
> > printk(".");
> > printk("|\n");
> > }
>
> Why don't you just allocate memory ?
That would work.
> To prevent the OOM kill you can just check for a variable
> in the OOM slow path. No need to rely on any particular
> behaviour of the VM.
>
Sure.
I'm not sure why swsusp needs "half of memory to be free"? What's
the story there?
I'd recommend that you sit in a loop, allocating pages with an
allocation mode of
__GFP_HIGHMEM | __GFP_WAIT
This will give you all the easily-reclaimable pages in the machine,
without trashing the page reserves (no __GFP_HIGH).
String all the pages together via page->list and when you have "enough",
free them all again.
prev parent reply other threads:[~2002-09-13 21:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-13 21:00 Good way to free as much memory as possible under 2.5.34? Pavel Machek
2002-09-13 21:09 ` Rik van Riel
2002-09-13 21:29 ` Pavel Machek
2002-09-13 21:33 ` Rik van Riel
2002-09-13 21:48 ` Xavier Bestel
2002-09-13 22:42 ` Rik van Riel
2002-09-13 23:26 ` Xavier Bestel
2002-09-13 21:53 ` Andrew Morton
2002-09-13 22:10 ` William Lee Irwin III
2002-09-14 10:05 ` Pavel Machek
2002-09-14 13:57 ` Andrew Morton
2002-09-14 14:51 ` Hans-Peter Jansen
2002-09-14 15:07 ` Rik van Riel
2002-09-14 15:11 ` Pavel Machek
2002-09-13 21:30 ` Andrew Morton [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D825907.493B4DB3@digeo.com \
--to=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=riel@conectiva.com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.