From: "Aubrey Li" <aubreylee@gmail.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Christoph Lameter <clameter@sgi.com>,
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Robin Getz <rgetz@blackfin.uclinux.org>,
"Frysinger, Michael" <Michael.Frysinger@analog.com>,
Bryan Wu <cooloney.lkml@gmail.com>,
"Hennerich, Michael" <Michael.Hennerich@analog.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] Limit the size of the pagecache
Date: Thu, 25 Jan 2007 10:27:43 +0800 [thread overview]
Message-ID: <6d6a94c50701241827y715353ccwb8c4b4697e5607ca@mail.gmail.com> (raw)
In-Reply-To: <1169650616.6189.41.camel@twins>
On 1/24/07, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> On Wed, 2007-01-24 at 22:22 +0800, Aubrey Li wrote:
> > On 1/24/07, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > > On Tue, 2007-01-23 at 16:49 -0800, Christoph Lameter wrote:
> > > > This is a patch using some of Aubrey's work plugging it in what is IMHO
> > > > the right way. Feel free to improve on it. I have gotten repeatedly
> > > > requests to be able to limit the pagecache. With the revised VM statistics
> > > > this is now actually possile. I'd like to know more about possible uses of
> > > > such a feature.
> > > >
> > > >
> > > >
> > > >
> > > > It may be useful to limit the size of the page cache for various reasons
> > > > such as
> > > >
> > > > 1. Insure that anonymous pages that may contain performance
> > > > critical data is never subject to swap.
> > >
> > > This is what we have mlock for, no?
> > >
> > > > 2. Insure rapid turnaround of pages in the cache.
> > >
> > > This sounds like we either need more fadvise hints and/or understand why
> > > the VM doesn't behave properly.
> > >
> > > > 3. Reserve memory for other uses? (Aubrey?)
> > >
> > > He wants to make a nommu system act like a mmu system; this will just
> > > never ever work.
> >
> > Nope. Actually my nommu system works great with some of patches made by us.
> > What let you think this will never work?
>
> Because there are perfectly valid things user-space can do to mess you
> up. I forgot the test-case but it had something to do with opening a
> million files, this will scatter slab pages all over the place.
>
> Also, if you cycle your large user-space allocations a bit unluckily
> you'll also fragment it into oblivion.
>
> So you can not guarantee it will not fragment into smithereens stopping
> your user-space from using large than page size allocations.
>
> If your user-space consists of several applications that do dynamic
> memory allocation of various sizes its a matter of (run-) time before
> things will start failing.
>
> If you prealloc a large area at boot time (like we now do for hugepages)
> and use that for user-space, you might 'reset' the status quo by cycling
> the whole of userspace.
>
It seems you are talking about a perfect system. Opening a million
files will never be the requirement of my system. You know I'm working
on an embedded system, most of the time the whole system just run for
one application, if I can guarantee this application works forever, I
think it's enough. I'm not trying to make a nommu system act like a
mmu system, it's impossible, I just make my nommu system work.
-Aubrey
--
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-01-25 2:27 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-24 0:49 Christoph Lameter
2007-01-24 2:53 ` KAMEZAWA Hiroyuki
2007-01-24 3:01 ` Christoph Lameter
2007-01-24 5:47 ` Aubrey Li
2007-01-24 3:00 ` Nick Piggin
2007-01-24 3:14 ` Christoph Lameter
2007-01-24 3:51 ` Aubrey Li
2007-01-24 4:03 ` Nick Piggin
2007-01-26 10:27 ` Andrew Morton
2007-01-24 3:13 ` KAMEZAWA Hiroyuki
2007-01-24 4:30 ` Christoph Lameter
2007-01-24 5:15 ` KAMEZAWA Hiroyuki
2007-01-25 0:32 ` KAMEZAWA Hiroyuki
2007-01-25 2:41 ` Christoph Lameter
2007-01-25 3:12 ` KAMEZAWA Hiroyuki
2007-01-25 4:28 ` Rik van Riel
2007-01-25 5:19 ` KAMEZAWA Hiroyuki
2007-01-25 5:40 ` Rik van Riel
2007-01-25 6:00 ` KAMEZAWA Hiroyuki
2007-01-26 10:29 ` Andrew Morton
2007-01-26 18:01 ` KAMEZAWA Hiroyuki
2007-01-24 7:04 ` Vaidyanathan Srinivasan
2007-01-24 7:55 ` Peter Zijlstra
2007-01-24 12:50 ` Nick Piggin
2007-01-24 12:58 ` Peter Zijlstra
2007-01-24 14:58 ` Christoph Lameter
2007-01-24 20:06 ` Erik Andersen
2007-01-25 2:40 ` Christoph Lameter
2007-01-25 8:07 ` Vaidyanathan Srinivasan
2007-01-24 14:22 ` Aubrey Li
2007-01-24 14:56 ` Peter Zijlstra
2007-01-25 2:27 ` Aubrey Li [this message]
2007-01-24 12:33 ` Vaidyanathan Srinivasan
2007-01-24 14:56 ` Christoph Lameter
2007-01-25 4:17 ` Vaidyanathan Srinivasan
2007-01-25 4:45 ` Rik van Riel
2007-01-25 5:49 ` Vaidyanathan Srinivasan
2007-01-25 16:07 ` Rik van Riel
2007-01-25 17:57 ` Balbir Singh
2007-01-25 6:35 ` Aubrey Li
2007-01-25 6:47 ` Christoph Lameter
2007-01-25 7:49 ` Vaidyanathan Srinivasan
2007-01-25 4:18 ` Rik van Riel
[not found] <7GEEK-4lH-39@gated-at.bofh.it>
[not found] ` <7GLdb-5Uz-13@gated-at.bofh.it>
[not found] ` <7GRix-7fU-1@gated-at.bofh.it>
[not found] ` <7GRLZ-7Uy-29@gated-at.bofh.it>
2007-01-25 14:51 ` Bodo Eggert
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=6d6a94c50701241827y715353ccwb8c4b4697e5607ca@mail.gmail.com \
--to=aubreylee@gmail.com \
--cc=Michael.Frysinger@analog.com \
--cc=Michael.Hennerich@analog.com \
--cc=a.p.zijlstra@chello.nl \
--cc=clameter@sgi.com \
--cc=cooloney.lkml@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
--cc=rgetz@blackfin.uclinux.org \
--cc=svaidy@linux.vnet.ibm.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