From: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: balbir@in.ibm.com, vatsa@in.ibm.com,
ckrm-tech@lists.sourceforge.net, devel@openvz.org, xemul@sw.ru,
menage@google.com, clameter@sgi.com, riel@redhat.com
Subject: [PATCH 0/3][RFC] Containers: Pagecache accounting and control subsystem (v1)
Date: Wed, 21 Feb 2007 19:54:51 +0530 [thread overview]
Message-ID: <20070221142451.193001000@linux.vnet.ibm.com> (raw)
-----------------------------------------------------------
This patch adds pagecache accounting and control on top of
Paul's container subsystem v7 posted at
http://lkml.org/lkml/2007/2/12/88
and Balbir's RSS controller posted at
http://lkml.org/lkml/2007/2/19/10
This patchset depends on Balbir's RSS controller and cannot
work independent of it. The page reclaim code has been merged
with container RSS controller. However compile time options
can individually enable/disable memory controller and/or
pagecache controller.
Comments, suggestions and criticisms are welcome.
Features:
--------
* New subsystem called 'pagecache_acct' is registered with containers
* Container pointer is added to struct address_space to keep track of
associated container
* In filemap.c and swap_state.c, the corresponding container's
pagecache_acct subsystem is charged and uncharged whenever a new
page is added or removed from pagecache
* The accounting number include pages in swap cache and filesystem
buffer pages apart from pagecache, basically everything under
NR_FILE_PAGES is counted as pagecache. However this excluded
mapped and anonymous pages
* Limits on pagecache can be set by echo 100000 > pagecache_limit on
the /container file system. The unit is in kilobytes
* If the pagecache utilisation limit is exceeded, pagecache reclaim
code is invoked to recover dirty and clean pagecache pages only.
Advantages:
-----------
* Does not add container pointers in struct page
Limitations:
-----------
* Code is not safe for container deletion/task migration
* Pagecache page reclaim needs performance improvements
* Global LRU is churned in search of pagecache pages
Usage:
-----
* Add patch on top of Paul container (v7) at kernel version 2.6.20
* Enable CONFIG_CONTAINER_PAGECACHE_ACCT in 'General Setup'
* Boot new kernel
* Mount container filesystem
mount -t container /container
cd /container
* Create new container
mkdir mybox
cd /container/mybox
* Add current shell to container
echo $$ > tasks
* There are two files pagecache_usage and pagecache_limit
* In order to set limit, echo value in kilobytes to pagecache_limit
echo 100000 > pagecache_limit
#This would set 100MB limit on pagecache usage
* Trash the system from current shell using scp/cp/dd/tar etc
* Watch pagecache_usage and /proc/meminfo to verify behavior
* Only unmapped pagecache data will be accounted and controlled.
These are memory used by cp, scp, tar etc. While file mmap will
be controlled by Balbir's RSS controller.
ToDo:
----
* Merge with container RSS controller and eliminate redundant code
* Support and test task migration and container deletion
* Review reclaim performance
* Optimise page reclaim
--
--
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 reply other threads:[~2007-02-21 14:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-21 14:24 Vaidyanathan Srinivasan [this message]
2007-02-21 14:24 ` [PATCH 1/3][RFC] Containers: Pagecache controller setup Vaidyanathan Srinivasan
2007-02-21 14:24 ` [PATCH 2/3][RFC] Containers: Pagecache controller accounting Vaidyanathan Srinivasan
2007-02-21 14:24 ` [PATCH 3/3][RFC] Containers: Pagecache controller reclaim 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-06 8:23 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=20070221142451.193001000@linux.vnet.ibm.com \
--to=svaidy@linux.vnet.ibm.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).