LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Aubrey Li" <aubreylee@gmail.com>
To: "Nick Piggin" <nickpiggin@yahoo.com.au>
Cc: "Vaidyanathan Srinivasan" <svaidy@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	"Linus Torvalds" <torvalds@osdl.org>,
	"Andrew Morton" <akpm@osdl.org>,
	"linux-os (Dick Johnson)" <linux-os@analogic.com>,
	"Robin Getz" <rgetz@blackfin.uclinux.org>,
	"Hennerich, Michael" <Michael.Hennerich@analog.com>
Subject: Re: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache
Date: Sat, 20 Jan 2007 12:26:13 +0800	[thread overview]
Message-ID: <6d6a94c50701192026q4aad8954s2d2aaa6b66ab1fd0@mail.gmail.com> (raw)
In-Reply-To: <45B19483.6010300@yahoo.com.au>

On 1/20/07, Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> Aubrey Li wrote:
>
> > So what's the right way to limit pagecache?
>
> Probably something a lot more complicated... if you can say there
> is a "right way".
>
> >> Secondly, your patch isn't actually very good. It unconditionally
> >> shrinks memory to below the given % mark each time a pagecache alloc
> >> occurs, regardless of how much pagecache is in the system. Effectively
> >> that seems to just reduce the amount of memory available to the system.
> >
> >
> > It doesn't reduce the amount of memory available to the system. It
> > just reduce the amount of memory available to the page cache. So that
> > page cache is limited and the reserved memory can be allocated by the
> > application.
>
> But the patch doesn't do that, as I explained.

I'm not sure you read the correct patch. Let me explain the logic again.

assume:
min = 123pages
pagecache_reserved = 200 pages

if( alloc_flags & ALLOC_PAGECACHE)
        watermark = min + pagecache_reserved ( 323 pages)
else
        watermark = min ( 123 pages)

So if request pagecache, when free pages < 323 pages, reclaim is triggered.
But at this time if request memory not pagecache, reclaim will be
triggered when free pages < 123 as the present reclaimer does.

I verified it on my side, why do you think it doesn't work properly?

>
> >> Luckily, there are actually good, robust solutions for your higher
> >> order allocation problem. Do higher order allocations at boot time,
> >> modifiy userspace applications, or set up otherwise-unused, or easily
> >> reclaimable reserve pools for higher order allocations. I don't
> >> understand why you are so resistant to all of these approaches?
> >>
> >
> > I think we have explained the reason too much. We are working on
> > no-mmu arch and provide a platform running linux to our customer. They
> > are doing very good things like mplayer, asterisk, ip camera, etc on
> > our platform, some applications was migrated from mmu arch. I think
> > that means in some cases no-mmu arch is somewhat better than mmu arch.
> > So we are taking effort to make the migration smooth or make no-mmu
> > linux stronger.
> > It's no way to let our customer modify their applications, we also
> > unwilling to do it. And we have not an existing mechanism to set up a
> > pools for the complex applications. So I'm trying to do some coding
> > hack in the kernel to satisfy these kinds of requirement.
>
> Oh, maybe you misunderstand the reserve pools idea: that is an entirely
> kernel based solution where you can preallocate a large, contiguous
> pool of memory at boot time which you can use to satisfy your nommu
> higher order anonymous memory allocations.
>
> This is something that will not get fragmented by pagecache, nor will
> it get fragmented by any other page allocation, slab allocation. Tt is
> a pretty good solution provided that you size the pool correctly for
> your application's needs.
>

So if application malloc(1M), how does kernel know to allocate
reserved pool not from buddy system? I didn't see any special code
about this. Is there any doc or example?

-Aubrey

  reply	other threads:[~2007-01-20  4:26 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-18  3:23 Aubrey Li
2007-01-19 14:44 ` Vaidyanathan Srinivasan
2007-01-19 15:40   ` Aubrey Li
2007-01-24  5:30     ` Vaidyanathan Srinivasan
2007-01-24  5:53       ` Aubrey Li
2007-01-19 14:52 ` Vaidyanathan Srinivasan
2007-01-19 16:05   ` Aubrey Li
2007-01-19 18:49     ` Vaidyanathan Srinivasan
2007-01-19 19:01       ` Christoph Lameter
2007-01-20  2:04       ` Aubrey Li
2007-01-20  2:24         ` Nick Piggin
2007-01-20  2:35           ` Mike Frysinger
2007-01-20  2:49             ` Nick Piggin
2007-01-20  3:40               ` Mike Frysinger
2007-01-20  3:08           ` Aubrey Li
2007-01-20  4:03             ` Nick Piggin
2007-01-20  4:26               ` Aubrey Li [this message]
2007-01-22 19:22                 ` Christoph Lameter
2007-01-22 19:15               ` Christoph Lameter
2007-01-19 18:21 ` 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=6d6a94c50701192026q4aad8954s2d2aaa6b66ab1fd0@mail.gmail.com \
    --to=aubreylee@gmail.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-os@analogic.com \
    --cc=nickpiggin@yahoo.com.au \
    --cc=rgetz@blackfin.uclinux.org \
    --cc=svaidy@linux.vnet.ibm.com \
    --cc=torvalds@osdl.org \
    --subject='Re: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).