From: Christoph Lameter <clameter@sgi.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, riel <riel@redhat.com>
Subject: Re: [RFC 0/7] Postphone reclaim laundry to write at high water marks
Date: Wed, 22 Aug 2007 12:04:51 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0708221157180.13813@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <1187766156.6114.280.camel@twins>
On Wed, 22 Aug 2007, Peter Zijlstra wrote:
> Its unavoidable, at some point it just happens. Also using reclaim
> doesn't seem like the ideal way to get out of live-locks since reclaim
> itself can live-lock on these large boxen.
If reclaim can live lock then it needs to be fixed.
> As shown, there are cases where there just isn't any memory to reclaim.
> Please accept this.
That is an extreme case that AFAIK we currently ignore and could be
avoided with some effort. The initial PF_MEMALLOC patchset seems to be
still enough to deal with your issues.
> Also, by reclaiming memory and getting out of the tight spot you give
> the rest of the system access to that memory, and it can be used for
> other things than getting out of the tight spot.
The rest of the system may have their own tights spots. Language the "the
tight spot" sets up all sort of alarms over here since you seem to be
thinking about a system doing a single task. The system may be handling
multiple critical tasks on various devices that have various memory needs.
So multiple critical spots can happen concurrently in multiple
application contexts.
> You really want a separate allocation state that allows only reclaim to
> access memory.
We have that with PF_MEMALLOC.
> Also, failing a memory allocation isn't bad, why are you so worried
> about that? It happens all the time.
Its a performance impact and plainly does not make sense if there is
reclaimable memory availble. The common action of the vm is to reclaim if
there is a demand for memory. Now we suddenly abandon that approach?
--
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-22 19:04 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
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 [this message]
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.0708221157180.13813@schroedinger.engr.sgi.com \
--to=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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