linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
To: Aubrey Li <aubreylee@gmail.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, ckrm-tech@lists.sourceforge.net,
	Balbir Singh <balbir@in.ibm.com>,
	Srivatsa Vaddagiri <vatsa@in.ibm.com>,
	devel@openvz.org, xemul@sw.ru, Paul Menage <menage@google.com>,
	Christoph Lameter <clameter@sgi.com>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 3/3][RFC] Containers: Pagecache controller reclaim
Date: Tue, 27 Mar 2007 15:14:57 +0530	[thread overview]
Message-ID: <4608E799.2050801@linux.vnet.ibm.com> (raw)
In-Reply-To: <6d6a94c50703270141u5e59f73dj8bef0de0cfed1924@mail.gmail.com>


Aubrey Li wrote:
> On 3/27/07, Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> wrote:
>> Correct, shrink_page_list() is called from shrink_inactive_list() but
>> the above code is patched in shrink_active_list().  The
>> 'force_reclaim_mapped' label is from function shrink_active_list() and
>> not in shrink_page_list() as it may seem in the patch file.
>>
>> While removing pages from active_list, we want to select only
>> pagecache pages and leave the remaining in the active_list.
>> page_mapped() pages are _not_ of interest to pagecache controller
>> (they will be taken care by rss controller) and hence we put it back.
>>  Also if the pagecache controller is below limit, no need to reclaim
>> so we put back all pages and come out.
> 
> Oh, I just read the patch, not apply it to my local tree, I'm working
> on 2.6.19 now.
> So the question is, when vfs pagecache limit is hit, the current
> implementation just reclaim few pages, so it's quite possible the
> limit is hit again, and hence the reclaim code will be called again
> and again, that will impact application performance.

Yes, you are correct.  So if we start reclaiming one page at a time,
then the cost of reclaim is very high and we would be calling the
reclaim code too often.  Hence we have a 'buffer zone' or 'reclaim
threshold' or 'push back' around the limit.  In the patch we have a 64
page (256KB) NR_PAGES_RECLAIM_THRESHOLD:

 int pagecache_acct_shrink_used(unsigned long nr_pages)
 {
 	unsigned long ret = 0;
 	atomic_inc(&reclaim_count);
+
+	/* Don't call reclaim for each page above limit */
+	if (nr_pages > NR_PAGES_RECLAIM_THRESHOLD) {
+		ret += shrink_container_memory(
+				RECLAIM_PAGECACHE_MEMORY, nr_pages, NULL);
+	}
+
 	return 0;
 }

Hence we do not call the reclaimer if the threshold is exceeded by
just 1 page... we wait for 64 pages or 256KB of pagecache memory to go
 overlimit and then call the reclaimer which will reclaim all 64 pages
in one shot.

This prevents the reclaim code from being called too often and it also
keeps the cost of reclaim low.

In future patches we are planing to have a percentage based reclaim
threshold so that it would scale well with the container size.

--Vaidy

--
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>

  reply	other threads:[~2007-03-27 10:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-06  8:23 [PATCH 0/3][RFC] Containers: Pagecache accounting and control subsystem (v1) Vaidyanathan Srinivasan
2007-03-06  8:26 ` [PATCH 1/3][RFC] Containers: Pagecache controller setup Vaidyanathan Srinivasan
2007-03-06  8:29 ` [PATCH 3/3][RFC] Containers: Pagecache controller reclaim Vaidyanathan Srinivasan
2007-03-06 10:24   ` Kari Hurtta
2007-03-06 11:19     ` Vaidyanathan Srinivasan
2007-03-27  3:44   ` Aubrey Li
2007-03-27  7:17     ` Vaidyanathan Srinivasan
2007-03-27  8:41       ` Aubrey Li
2007-03-27  9:44         ` Vaidyanathan Srinivasan [this message]
2007-03-27 10:53           ` Aubrey Li
2007-03-27 12:25             ` Vaidyanathan Srinivasan
  -- strict thread matches above, loose matches on Subject: below --
2007-03-05 14:52 [PATCH 0/3][RFC] Containers: Pagecache accounting and control subsystem (v1) Vaidyanathan Srinivasan
2007-03-05 14:52 ` [PATCH 3/3][RFC] Containers: Pagecache controller reclaim Vaidyanathan Srinivasan
2007-02-21 14:24 [PATCH 0/3][RFC] Containers: Pagecache accounting and control subsystem (v1) Vaidyanathan Srinivasan
2007-02-21 14:24 ` [PATCH 3/3][RFC] Containers: Pagecache controller reclaim Vaidyanathan Srinivasan

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=4608E799.2050801@linux.vnet.ibm.com \
    --to=svaidy@linux.vnet.ibm.com \
    --cc=aubreylee@gmail.com \
    --cc=balbir@in.ibm.com \
    --cc=ckrm-tech@lists.sourceforge.net \
    --cc=clameter@sgi.com \
    --cc=devel@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=menage@google.com \
    --cc=riel@redhat.com \
    --cc=vatsa@in.ibm.com \
    --cc=xemul@sw.ru \
    /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;
as well as URLs for NNTP newsgroup(s).