All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Emelianov <xemul@openvz.org>
To: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@osdl.org>,
	Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
	Linux Containers <containers@lists.osdl.org>,
	Paul Menage <menage@google.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Kirill Korotaev <dev@openvz.org>
Subject: Re: [-mm PATCH 0/7] Memory controller introduction
Date: Thu, 05 Jul 2007 13:14:00 +0400	[thread overview]
Message-ID: <468CB658.7000204@openvz.org> (raw)
In-Reply-To: <20070704222108.17702.40293.sendpatchset@balbir-laptop>

Balbir Singh wrote:
> Resending with the patch numbering fixed and linux-mm copied
> 
> This patchset implements another version of the memory controller. These
> patches have been through a big churn, the first set of patches were posted
> last year and earlier this year at
> 	http://lkml.org/lkml/2007/2/19/10
> 
> Ever since, the RSS controller has been through four revisions, the latest
> one being
> 	http://lwn.net/Articles/236817/
> 
> This patchset draws from the patches listed above and from some of the
> contents of the patches posted by Vaidyanathan for page cache control.
> 	http://lkml.org/lkml/2007/6/20/92
> 
> Pavel, Vaidy could you look at the patches and add your signed off by
> where relevant?

As far as I remember at OLS we decided to implement per-zone RLU
lists and reuse the lru lock as well. This will remove all the 
problems with per-container lists inconsistency.

Separate limits for RSS and RSS+pagecache are also a must.

BTW, if you send smb. else's patches you may include a 'From: xxx'
line into the letter to address the original author.

> At OLS, the resource management BOF, it was discussed that we need to manage
> RSS and unmapped page cache together. This patchset is a step towards that
> 
> TODO's
> 
> 1. Add memory controller water mark support. Reclaim on high water mark
> 2. Add support for shrinking on limit change
> 3. Add per zone per container LRU lists
> 4. Make page_referenced() container aware
> 5. Figure out a better CLUI for the controller
> 
> In case you have been using/testing the RSS controller, you'll find that
> this controller works slower than the RSS controller. The reason being
> that both swap cache and page cache is accounted for, so pages do go
> out to swap upon reclaim (they cannot live in the swap cache).
> 
> I've test compiled the framework without the controller enabled, tested
> the code on UML and minimally on a power box.
> 
> Any test output, feedback, comments, suggestions are welcome!
> 
> series
> 
> res_counters_infra.patch
> mem-control-setup.patch
> mem-control-accounting-setup.patch
> mem-control-accounting.patch
> mem-control-task-migration.patch
> mem-control-lru-and-reclaim.patch
> mem-control-out-of-memory.patch
> 


  parent reply	other threads:[~2007-07-05  8:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-04 22:21 [-mm PATCH 0/7] Memory controller introduction Balbir Singh
2007-07-04 22:21 ` [-mm PATCH 1/7] Memory controller resource counters Balbir Singh
2007-07-04 22:21 ` [-mm PATCH 2/7] Memory controller containers setup Balbir Singh
2007-07-04 22:21 ` [-mm PATCH 3/7] Memory controller accounting setup Balbir Singh
2007-07-04 22:22 ` [-mm PATCH 4/7] Memory controller memory accounting Balbir Singh
2007-07-05 18:46   ` Vaidyanathan Srinivasan
2007-07-05 20:03     ` Balbir Singh
2007-07-04 22:22 ` [-mm PATCH 5/7] Memory controller task migration Balbir Singh
2007-07-04 22:22 ` [-mm PATCH 6/7] Memory controller add per container LRU and reclaim Balbir Singh
2007-07-04 22:22 ` [-mm PATCH 7/7] Memory controller OOM handling Balbir Singh
2007-07-05  9:14 ` Pavel Emelianov [this message]
2007-07-05 14:32   ` [-mm PATCH 0/7] Memory controller introduction Balbir Singh
2007-07-06 13:14   ` Peter Zijlstra
2007-07-06 14:06     ` Pavel Emelianov
2007-07-06 15:34     ` Balbir Singh
  -- strict thread matches above, loose matches on Subject: below --
2007-07-04 22:12 Balbir Singh

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=468CB658.7000204@openvz.org \
    --to=xemul@openvz.org \
    --cc=akpm@osdl.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=containers@lists.osdl.org \
    --cc=dev@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=menage@google.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.