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



Aubrey Li wrote:
> On 1/19/07, Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> wrote:
>>
>> Hi Aubrey,
>>
>> The idea of creating separate flag for pagecache in page_alloc is
>> interesting.  The good part is that you flag watermark low and the
>> zone reclaimer will do the rest of the job.
>>
>> However when the zone reclaimer starts to reclaim pages, it will
>> remove all cold pages and not specifically pagecache pages.  This
>> may affect performance of applications.
>>
>> One possible solution to this reclaim is to use scan control fields
>> and ask the shrink_page_list() and shrink_active_list() routines to
>> target only pagecache pages.  Pagecache pages are not mapped and
>> they are easy to find on the LRU list.
>>
>> Please review my patch at http://lkml.org/lkml/2007/01/17/96
>>
> 
> So you mean the existing reclaimer has the same issue, doesn't it?

Well, the existing reclaimer will do the right job if the kernel
really runs out of memory and need to recover pages for new
allocations.  The pages to be removed will be the coldest page in
the system.  However now with the introduction of pagecache limit,
we are artificially creating a memory scarcity and forcing the
reclaimer to throw away some pages while we actually have free
usable RAM.  In this context the choice of pages picked by the
present reclaimer may not be the best ones.

If pagecache is overlimit, we expect old (cold) pagecache pages to
be thrown out and reused for new file data.  We do not expect to
drop a few text or data pages to make room for new pagecache.

> In your and Roy's patch, balance_pagecache() routine is called on file
> backed access.
> So you still want to add this checking? or change the current
> reclaimer completely?

The balance_pagecache() routine is called for file backed access
since that is when we would probably exceed the pagecache limit.
The routine check if the limit has exceeded and calls the reclaimer.
The reclaimer is an extension of the present reclaimer with more
checks to remove only pagecache pages and not try to unmap any
mapped pages and potentially affect application performance.

I am open to suggestions on reclaim logic.  My view is that we need
to selectively reclaim pagecache pages and not just call the
traditional reclaimer to freeup arbitrary type of pages.

--Vaidy

> -Aubrey
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

  reply	other threads:[~2007-01-19 18:49 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 [this message]
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
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=45B112B6.9060806@linux.vnet.ibm.com \
    --to=svaidy@linux.vnet.ibm.com \
    --cc=akpm@osdl.org \
    --cc=aubreylee@gmail.com \
    --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=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).