From: Christoph Lameter <clameter@sgi.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Rik van Riel <riel@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-mm@kvack.org, dkegel@google.com, akpm@linux-foundation.org,
Nick Piggin <npiggin@suse.de>,
ak@suse.de, linux-kernel@vger.kernel.org
Subject: Re: [RFC 0/7] Postphone reclaim laundry to write at high water marks
Date: Thu, 23 Aug 2007 13:23:00 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0708231318100.14720@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20070823120506.GN13915@v2.random>
On Thu, 23 Aug 2007, Andrea Arcangeli wrote:
> On Tue, Aug 21, 2007 at 03:32:25PM -0700, Christoph Lameter wrote:
> > 1. Like in the earlier patchset allow reentry to reclaim under
> > PF_MEMALLOC if we are out of all memory.
>
> Can you simply tweak on the may_writepage flag only to achieve the
> second pass? We're talking here about a totally non-performance case,
> almost impossible to hit in practice unless you do real weird things,
> and certainly very unlikely to happen. So I'm unsure what's all that
> complexity just to make a regular pass on the lru looking for clean
> pages, something may_writepage=0 already does.
>
Yes that is what the PF_MEMALLOC patch that I posted before does. This
discussion gets me more and more to thinking that the recursive reclaim on
PF_MEMALLOC is all that is needed for emergency situations (to get out of
the "tight spot").
See
http://marc.info/?l=linux-kernel&m=118710219116624&w=2
> If the PF_MEMALLOC is found empty, I agree entering reclaim a second
> time with may_writepage=0 sounds theoretically a good idea (in
> practice it should never be necessary). printk must also be printed to
> warn the user he was risking to deadlock for real and he has to
> increase the min_free_kbytes.
Ok. I can add a printk to that one.
> That sounds a bit risky, there are latency considerations here to
> make, GFP_ATOMIC will run with irq locally disabled and it may hang
> for indefinite amount of time (O(N)). So irq latency may break and it
> may be better to lose a packet once in a while than to hang
> interrupts. If you want to do this you'd probably need to add a new
> GFP_ATOMIC_RECLAIM or similar.
Well we could do the same as for PF_MEMALLOC: print a warning and then
reclaim nevertheless if we cannot fail (We already have a GFP_NOFAIL
flag). It is better to generate a latency than the system failing
altogether. However the GFP_ATOMIC reclaim patchset is a
bit more invasive (http://marc.info/?l=linux-mm&m=118710584014150&w=2).
Maybe this is too much churn for the rare need of such a reclaim.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-08-23 20:23 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-20 21:50 Christoph Lameter
2007-08-20 21:50 ` [RFC 1/7] release_lru_pages(): Generic release of pages to the LRU Christoph Lameter
2007-08-21 14:52 ` Mel Gorman
2007-08-21 20:51 ` Christoph Lameter
2007-08-20 21:50 ` [RFC 2/7] Move checks from pageout() to shrink_page_list Christoph Lameter
2007-08-20 21:50 ` [RFC 3/7] shrink_page_list: Support isolating dirty pages on laundry list Christoph Lameter
2007-08-21 15:04 ` Mel Gorman
2007-08-21 20:53 ` Christoph Lameter
2007-08-20 21:50 ` [RFC 4/7] Pass laundry through shrink_inactive_list() and shrink_zone() Christoph Lameter
2007-08-20 21:50 ` [RFC 5/7] Laundry handling for direct reclaim Christoph Lameter
2007-08-21 15:06 ` Mel Gorman
2007-08-21 20:55 ` Christoph Lameter
2007-08-21 15:19 ` Mel Gorman
2007-08-21 21:00 ` Christoph Lameter
2007-08-20 21:50 ` [RFC 6/7] kswapd: Do laundry after reclaim Christoph Lameter
2007-08-20 21:50 ` [RFC 7/7] Switch of PF_MEMALLOC during writeout Christoph Lameter
2007-08-20 23:08 ` Andi Kleen
2007-08-20 23:19 ` Christoph Lameter
2007-08-21 1:13 ` Andi Kleen
2007-08-21 10:36 ` [RFC 0/7] Postphone reclaim laundry to write at high water marks Peter Zijlstra
2007-08-21 20:48 ` Christoph Lameter
2007-08-21 21:13 ` Peter Zijlstra
2007-08-21 21:29 ` Christoph Lameter
2007-08-21 21:43 ` Rik van Riel
2007-08-21 22:32 ` Christoph Lameter
2007-08-23 12:05 ` Andrea Arcangeli
2007-08-23 20:23 ` Christoph Lameter [this message]
2007-08-21 22:09 ` Peter Zijlstra
2007-08-21 22:43 ` Christoph Lameter
2007-08-22 7:02 ` Peter Zijlstra
2007-08-22 19:04 ` Christoph Lameter
2007-08-22 20:03 ` Peter Zijlstra
2007-08-22 20:16 ` Christoph Lameter
2007-08-23 7:39 ` Peter Zijlstra
2007-08-26 4:52 ` Rik van Riel
2007-08-23 12:16 ` Andrea Arcangeli
2007-08-22 7:45 ` Ingo Molnar
2007-08-22 19:19 ` Christoph Lameter
2007-08-23 12:08 ` Andrea Arcangeli
2007-08-23 12:59 ` Peter Zijlstra
2007-08-21 15:16 ` Rik van Riel
2007-08-21 20:59 ` Christoph Lameter
2007-08-21 21:14 ` Rik van Riel
2007-08-21 21:30 ` Christoph Lameter
2007-08-21 15:51 ` Dave McCracken
2007-08-21 21:03 ` Christoph Lameter
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=Pine.LNX.4.64.0708231318100.14720@schroedinger.engr.sgi.com \
--to=clameter@sgi.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=andrea@suse.de \
--cc=dkegel@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
--cc=peterz@infradead.org \
--cc=riel@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox