All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Peter Osterlund <petero2@telia.com>,
	linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: Can't make use of swap memory in 2.6.7-bk19
Date: Thu, 8 Jul 2004 18:53:17 -0700	[thread overview]
Message-ID: <20040709015317.GR21066@holomorphy.com> (raw)
In-Reply-To: <40EDED5D.80605@yahoo.com.au>

William Lee Irwin III wrote:
>> Oh, then I'm stuck in the GFP_WIRED quagmire after all. I guess since
>> fixing it involves adding lines I'm in deep trouble.

On Fri, Jul 09, 2004 at 10:57:01AM +1000, Nick Piggin wrote:
> Or just see if you can tighten up the conditions for OOM to
> start with?

You must not have seen the patches. the thread starts with Message-id:
<0406231407.HbLbJbXaHbKbWa5aJb1a4aKb0a3aKb1a0a2aMbMbYa3aLbMb3aJbWaJbXaMbLb1a342@holomorphy.com>

They added a flag indicating wiredness or no to the gfp_mask, which was
then propagated down the call chain and eventually passed as an argument
to out_of_memory(). In turn, out_of_memory() used the flag to determine
whether the nr_swap_pages > 0 check was relevant. i.e. they refined the
OOM conditions based on the wiredness of the failing allocation. What
probably got the stuff permavetoed was the stats reporting I did along
with it that would have been trivial to drop while retaining the needed
functional change. The patch was motivated by the nr_swap_pages > 0
check deadlocking. The __GFP_WIRED business was done to discriminate
the obvious deadlocking scenario from the false OOM mentioned here.

-- wli

  reply	other threads:[~2004-07-09  1:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-08  1:36 Can't make use of swap memory in 2.6.7-bk19 Peter Osterlund
2004-07-08  1:43 ` William Lee Irwin III
2004-07-08  2:14 ` Nick Piggin
2004-07-08  2:30   ` William Lee Irwin III
2004-07-08 12:59     ` Peter Osterlund
2004-07-08 19:39       ` William Lee Irwin III
2004-07-09  0:57         ` Nick Piggin
2004-07-09  1:53           ` William Lee Irwin III [this message]
2004-07-09  2:06             ` Nick Piggin
2004-07-09  2:09               ` William Lee Irwin III
2004-07-09  2:12                 ` Andrew Morton
2004-07-09  2:50                   ` William Lee Irwin III
2004-07-09  4:51                     ` Andrew Morton
2004-07-09  2:14                 ` Nick Piggin
2004-07-08  8:12   ` Peter Osterlund
2004-07-08  8:20     ` Andrew Morton
2004-07-08  8:23       ` Nick Piggin
2004-07-08  9:30         ` Peter Osterlund
2004-07-14  5:20           ` William Lee Irwin III
2004-07-14 10:39             ` Peter Osterlund
2004-07-14 10:57               ` William Lee Irwin III
2004-07-14 12:55                 ` Peter Osterlund
2004-07-14 13:22                   ` William Lee Irwin III
2004-07-14 20:00                     ` Peter Osterlund

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=20040709015317.GR21066@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=petero2@telia.com \
    /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.