From: Rik van Riel <riel@redhat.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Anton Altaparmakov <aia21@cam.ac.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
marc.smith@esmail.mcc.edu
Subject: Re: VM/VFS bug with large amount of memory and file systems?
Date: Tue, 18 Sep 2007 10:41:50 -0400 [thread overview]
Message-ID: <46EFE3AE.9040909@redhat.com> (raw)
In-Reply-To: <200709180312.31937.nickpiggin@yahoo.com.au>
Nick Piggin wrote:
> On Tuesday 18 September 2007 03:04, Rik van Riel wrote:
>> Nick Piggin wrote:
>>> (Rik has a patch sitting in -mm I believe which would make this problem
>>> even worse, by doing even less highmem scanning in response to lowmem
>>> allocations).
>> My patch should not make any difference here, since
>> balance_pgdat() already scans the zones from high to
>> low and sets an end_zone variable that determines the
>> highest zone to scan.
>>
>> All my patch does is make sure that we do not try to
>> reclaim excessive amounts of dma or low memory when
>> a higher zone is full.
>
> Sorry, yeah I had it the wrong way around. Your patch would not
> increase the probability of this problem.
>
> We could have some logic in there to scan highmem when buffer
> heads are over limit. But that really kind of sucks in that it introduces
> some arbitrary point where reclaim behaviour completely changes...
> Adding a shrinker for buffer heads is the "logical" approach
Christoph Lameter's slab defragmenting patch set does
this. One reason Andrew has not merged that code yet
is a lack of reviewers, so I am going through it with
a fine comb and hope to have the patches reviewed by
the end of today.
Lets get this bug fixed the right way.
--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other unpatriotic.
next prev parent reply other threads:[~2007-09-18 14:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-15 7:27 VM/VFS bug with large amount of memory and file systems? Anton Altaparmakov
2007-09-15 10:08 ` Peter Zijlstra
2007-09-15 10:50 ` Anton Altaparmakov
2007-09-15 11:19 ` Peter Zijlstra
2007-09-16 7:22 ` Kyle Moffett
2007-09-16 16:16 ` Peter Zijlstra
2007-09-15 10:52 ` Andrew Morton
2007-09-17 14:04 ` Anton Altaparmakov
2007-09-17 14:09 ` Anton Altaparmakov
2007-09-16 22:28 ` Nick Piggin
2007-09-17 17:04 ` Rik van Riel
2007-09-17 17:12 ` Nick Piggin
2007-09-18 14:41 ` Rik van Riel [this message]
2007-09-17 14:32 ` Peter Zijlstra
2007-09-17 17:11 ` Rik van Riel
2007-09-17 20:15 ` Andrew Morton
2007-09-17 20:46 ` Rik van Riel
2007-09-17 21:11 ` Andrew Morton
2007-09-19 22:12 ` Rik van Riel
2007-09-19 22:45 ` Andrew Morton
2007-09-19 22:50 ` Rik van Riel
2007-09-19 23:29 ` Christoph Lameter
2007-09-19 23:37 ` Andrew Morton
2007-10-03 10:51 ` Pavel Machek
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=46EFE3AE.9040909@redhat.com \
--to=riel@redhat.com \
--cc=aia21@cam.ac.uk \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=marc.smith@esmail.mcc.edu \
--cc=nickpiggin@yahoo.com.au \
--cc=peterz@infradead.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