linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: Andrew Morton <akpm@digeo.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: 2.5.73-mm2
Date: Mon, 30 Jun 2003 19:46:59 -0700	[thread overview]
Message-ID: <20030701024659.GD26348@holomorphy.com> (raw)
In-Reply-To: <20030630191456.1aef22e0.akpm@digeo.com>

William Lee Irwin III <wli@holomorphy.com> wrote:
>>  @@ -217,9 +217,9 @@ void out_of_memory(void)
>>   	unsigned long now, since;
>>   
>>   	/*
>>  -	 * Enough swap space left?  Not OOM.
>>  +	 * Enough swap space and ZONE_NORMAL left?  Not OOM.
>>   	 */
>>  -	if (nr_swap_pages > 0)
>>  +	if (nr_swap_pages > 0 && nr_free_buffer_pages() + nr_used_low_pages() > 0)
>>   		return;

On Mon, Jun 30, 2003 at 07:14:56PM -0700, Andrew Morton wrote:
> a) if someone is trying to allocate some ZONE_DMA pages and there are
>    still swappable or free ZONE_NORMAL pages, nobody gets killed.

This is yet another problem for the method above. =(


On Mon, Jun 30, 2003 at 07:14:56PM -0700, Andrew Morton wrote:
> b) If there are free ZONE_NORMAL pages then why on earth did we call
>    out_of_memory()?  Does nr_free_buffer_pages() ever return non-zero in
>    here?  It will do so for a ZONE_DMA allocation, but you're not doing
>    them...

Allocations will enter this path if free memory is below the minimum
page thresholds, since the allocation will be sort of artificially
failed. Basically, with this in place it's more likely to livelock than
to go on killing sprees. There's a small amount of empirical evidence
suggesting this avoids livelocking in some common scenarios, though
that really isn't good enough for this kind of affair.


On Mon, Jun 30, 2003 at 07:14:56PM -0700, Andrew Morton wrote:
> Generally, I'm thinking that this test should just be removed.  It is
> the responsibility of try_to_free_pages() to work out whether the
> allocation can succeed.
> If try_to_free_pages() calls out_of_memory() when there are still
> swappable, reclaimable or free pages in the relevant zones then
> try_to_free_pages() goofed, and needs mending.  out_of_memory()
> shouldn't be cleaning up after try_to_free_pages()'s mistakes.
> I have a bad feeling that it _will_ goof.  A long time ago I looked
> at the amount of scanning we're doing in there and decided that it
> was way overkill and reduced it by a lot.  I may have gone overboard.  
> So how's about I and thy take that test out, see how things get along?

I'm not particularly attached to the method, only the result, so I'm game.


-- wli

  reply	other threads:[~2003-07-01  2:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-28  3:21 2.5.73-mm2 Andrew Morton
2003-06-28  8:56 ` 2.5.73-mm2 William Lee Irwin III
2003-06-28 15:54 ` 2.5.73-mm2 William Lee Irwin III
2003-06-28 16:08   ` 2.5.73-mm2 Christoph Hellwig
2003-06-28 20:49     ` 2.5.73-mm2 William Lee Irwin III
2003-06-29  0:34     ` 2.5.73-mm2 Martin J. Bligh
2003-06-29  2:18       ` 2.5.73-mm2 William Lee Irwin III
2003-06-29  3:07         ` 2.5.73-mm2 Martin J. Bligh
2003-06-28 23:00   ` 2.5.73-mm2 Andrew Morton
2003-06-28 23:11     ` 2.5.73-mm2 William Lee Irwin III
2003-06-29 12:45       ` 2.5.73-mm2 Zwane Mwaikambo
2003-07-02  3:11   ` 2.5.73-mm2 William Lee Irwin III
2003-06-29 19:04 ` [patch] 2.5.73-mm2: let CONFIG_TC35815 depend on CONFIG_TOSHIBA_JMR3927 Adrian Bunk
2003-06-29 21:04   ` Ralf Baechle
2003-07-01  0:39 ` 2.5.73-mm2 William Lee Irwin III
2003-07-01  2:14   ` 2.5.73-mm2 Andrew Morton
2003-07-01  2:46     ` William Lee Irwin III [this message]
2003-07-01 10:46   ` 2.5.73-mm2 Hugh Dickins
2003-07-01 10:51     ` 2.5.73-mm2 William Lee Irwin III
2003-07-01 11:08       ` 2.5.73-mm2 Hugh Dickins
2003-07-01 11:08         ` 2.5.73-mm2 William Lee Irwin III
2003-07-01 12:39           ` 2.5.73-mm2 Nikita Danilov
2003-07-01  5:56 ` 2.5.73-mm2 William Lee Irwin III

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=20030701024659.GD26348@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).