All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: William Lee Irwin III <wli@holomorphy.com>
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: Fri, 09 Jul 2004 12:06:54 +1000	[thread overview]
Message-ID: <40EDFDBE.5040805@yahoo.com.au> (raw)
In-Reply-To: <20040709015317.GR21066@holomorphy.com>

William Lee Irwin III wrote:
> 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.
> 

No, I did see those patches. I'm not saying they're not worth
persuing; on the contrary, they look quite interesting. However,
it might worthwhile looking at more basic things first, for this
problem anyway.

  reply	other threads:[~2004-07-09  2:06 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
2004-07-09  2:06             ` Nick Piggin [this message]
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=40EDFDBE.5040805@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=petero2@telia.com \
    --cc=wli@holomorphy.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.