All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-mm@kvack.org, Sudhir Kumar <skumar@linux.vnet.ibm.com>,
	YAMAMOTO Takashi <yamamoto@valinux.co.jp>,
	Bharata B Rao <bharata@in.ibm.com>,
	Paul Menage <menage@google.com>,
	lizf@cn.fujitsu.com, linux-kernel@vger.kernel.org,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	David Rientjes <rientjes@google.com>,
	Pavel Emelianov <xemul@openvz.org>,
	Dhaval Giani <dhaval@linux.vnet.ibm.com>,
	Rik van Riel <riel@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 0/4] Memory controller soft limit patches (v4)
Date: Fri, 6 Mar 2009 15:35:34 +0530	[thread overview]
Message-ID: <20090306100534.GD5482@balbir.in.ibm.com> (raw)
In-Reply-To: <20090306185440.66b92ca3.kamezawa.hiroyu@jp.fujitsu.com>

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-03-06 18:54:40]:

> On Fri, 06 Mar 2009 14:53:23 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > 
> > From: Balbir Singh <balbir@linux.vnet.ibm.com>
> > 
> > New Feature: Soft limits for memory resource controller.
> > 
> > Changelog v4...v3
> > 1. Adopted suggestions from Kamezawa to do a per-zone-per-node reclaim
> >    while doing soft limit reclaim. We don't record priorities while
> >    doing soft reclaim
> > 2. Some of the overheads associated with soft limits (like calculating
> >    excess each time) is eliminated
> > 3. The time_after(jiffies, 0) bug has been fixed
> > 4. Tasks are throttled if the mem cgroup they belong to is being soft reclaimed
> >    and at the same time tasks are increasing the memory footprint and causing
> >    the mem cgroup to exceed its soft limit.
> > 
> I don't think this "4" is necessary.
>

I responded to it and I had asked for review for this. Lets discuss it
there. I am open to doing this or not.
 
> 
> > Changelog v3...v2
> > 1. Implemented several review comments from Kosaki-San and Kamezawa-San
> >    Please see individual changelogs for changes
> > 
> > Changelog v2...v1
> > 1. Soft limits now support hierarchies
> > 2. Use spinlocks instead of mutexes for synchronization of the RB tree
> > 
> > Here is v4 of the new soft limit implementation. Soft limits is a new feature
> > for the memory resource controller, something similar has existed in the
> > group scheduler in the form of shares. The CPU controllers interpretation
> > of shares is very different though. 
> > 
> > Soft limits are the most useful feature to have for environments where
> > the administrator wants to overcommit the system, such that only on memory
> > contention do the limits become active. The current soft limits implementation
> > provides a soft_limit_in_bytes interface for the memory controller and not
> > for memory+swap controller. The implementation maintains an RB-Tree of groups
> > that exceed their soft limit and starts reclaiming from the group that
> > exceeds this limit by the maximum amount.
> > 
> > If there are no major objections to the patches, I would like to get them
> > included in -mm.
> > 
> You got Nack from me, again ;) And you know why.
> I'll post my one later, I hope that one will be good input for you.
>

Lets discuss the patches and your objections. I suspect it is because
of 4 above, but I don't want to keep guessing. 

-- 
	Balbir

WARNING: multiple messages have this Message-ID (diff)
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-mm@kvack.org, Sudhir Kumar <skumar@linux.vnet.ibm.com>,
	YAMAMOTO Takashi <yamamoto@valinux.co.jp>,
	Bharata B Rao <bharata@in.ibm.com>,
	Paul Menage <menage@google.com>,
	lizf@cn.fujitsu.com, linux-kernel@vger.kernel.org,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	David Rientjes <rientjes@google.com>,
	Pavel Emelianov <xemul@openvz.org>,
	Dhaval Giani <dhaval@linux.vnet.ibm.com>,
	Rik van Riel <riel@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 0/4] Memory controller soft limit patches (v4)
Date: Fri, 6 Mar 2009 15:35:34 +0530	[thread overview]
Message-ID: <20090306100534.GD5482@balbir.in.ibm.com> (raw)
In-Reply-To: <20090306185440.66b92ca3.kamezawa.hiroyu@jp.fujitsu.com>

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-03-06 18:54:40]:

> On Fri, 06 Mar 2009 14:53:23 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > 
> > From: Balbir Singh <balbir@linux.vnet.ibm.com>
> > 
> > New Feature: Soft limits for memory resource controller.
> > 
> > Changelog v4...v3
> > 1. Adopted suggestions from Kamezawa to do a per-zone-per-node reclaim
> >    while doing soft limit reclaim. We don't record priorities while
> >    doing soft reclaim
> > 2. Some of the overheads associated with soft limits (like calculating
> >    excess each time) is eliminated
> > 3. The time_after(jiffies, 0) bug has been fixed
> > 4. Tasks are throttled if the mem cgroup they belong to is being soft reclaimed
> >    and at the same time tasks are increasing the memory footprint and causing
> >    the mem cgroup to exceed its soft limit.
> > 
> I don't think this "4" is necessary.
>

I responded to it and I had asked for review for this. Lets discuss it
there. I am open to doing this or not.
 
> 
> > Changelog v3...v2
> > 1. Implemented several review comments from Kosaki-San and Kamezawa-San
> >    Please see individual changelogs for changes
> > 
> > Changelog v2...v1
> > 1. Soft limits now support hierarchies
> > 2. Use spinlocks instead of mutexes for synchronization of the RB tree
> > 
> > Here is v4 of the new soft limit implementation. Soft limits is a new feature
> > for the memory resource controller, something similar has existed in the
> > group scheduler in the form of shares. The CPU controllers interpretation
> > of shares is very different though. 
> > 
> > Soft limits are the most useful feature to have for environments where
> > the administrator wants to overcommit the system, such that only on memory
> > contention do the limits become active. The current soft limits implementation
> > provides a soft_limit_in_bytes interface for the memory controller and not
> > for memory+swap controller. The implementation maintains an RB-Tree of groups
> > that exceed their soft limit and starts reclaiming from the group that
> > exceeds this limit by the maximum amount.
> > 
> > If there are no major objections to the patches, I would like to get them
> > included in -mm.
> > 
> You got Nack from me, again ;) And you know why.
> I'll post my one later, I hope that one will be good input for you.
>

Lets discuss the patches and your objections. I suspect it is because
of 4 above, but I don't want to keep guessing. 

-- 
	Balbir

--
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:[~2009-03-06 10:05 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-06  9:23 [PATCH 0/4] Memory controller soft limit patches (v4) Balbir Singh
2009-03-06  9:23 ` Balbir Singh
2009-03-06  9:23 ` [PATCH 1/4] Memory controller soft limit documentation (v4) Balbir Singh
2009-03-06  9:23   ` Balbir Singh
2009-03-06  9:23 ` [PATCH 2/4] Memory controller soft limit interface (v4) Balbir Singh
2009-03-06  9:23   ` Balbir Singh
2009-03-06  9:23 ` [PATCH 3/4] Memory controller soft limit organize cgroups (v4) Balbir Singh
2009-03-06  9:23   ` Balbir Singh
2009-03-06  9:23 ` [PATCH 4/4] Memory controller soft limit reclaim on contention (v4) Balbir Singh
2009-03-06  9:23   ` Balbir Singh
2009-03-06  9:51   ` KAMEZAWA Hiroyuki
2009-03-06  9:51     ` KAMEZAWA Hiroyuki
2009-03-06 10:01     ` Balbir Singh
2009-03-06 10:01       ` Balbir Singh
2009-03-06 10:14       ` KAMEZAWA Hiroyuki
2009-03-06 10:14         ` KAMEZAWA Hiroyuki
2009-03-06 10:41         ` Balbir Singh
2009-03-06 10:41           ` Balbir Singh
2009-03-06  9:54 ` [PATCH 0/4] Memory controller soft limit patches (v4) KAMEZAWA Hiroyuki
2009-03-06  9:54   ` KAMEZAWA Hiroyuki
2009-03-06 10:05   ` Balbir Singh [this message]
2009-03-06 10:05     ` Balbir Singh
2009-03-06 10:34   ` [RFC][PATCH 0/3] memory controller soft limit (Yet Another One) v1 KAMEZAWA Hiroyuki
2009-03-06 10:34     ` KAMEZAWA Hiroyuki
2009-03-06 10:36     ` [RFC][PATCH 1/3] soft limit interface (Yet Another One) KAMEZAWA Hiroyuki
2009-03-06 10:36       ` KAMEZAWA Hiroyuki
2009-03-06 10:37     ` [RFC][PATCH 2/3] memcg sotlimit logic " KAMEZAWA Hiroyuki
2009-03-06 10:37       ` KAMEZAWA Hiroyuki
2009-03-06 10:38     ` [RFC][PATCH 3/3] memcg documenation soft limit " KAMEZAWA Hiroyuki
2009-03-06 10:38       ` KAMEZAWA Hiroyuki
2009-03-06 16:47       ` Randy Dunlap
2009-03-06 16:47         ` Randy Dunlap
2009-03-08 23:44         ` KAMEZAWA Hiroyuki
2009-03-08 23:44           ` KAMEZAWA Hiroyuki
2009-03-08 23:45         ` KAMEZAWA Hiroyuki
2009-03-08 23:45           ` KAMEZAWA Hiroyuki

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=20090306100534.GD5482@balbir.in.ibm.com \
    --to=balbir@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=bharata@in.ibm.com \
    --cc=dhaval@linux.vnet.ibm.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=menage@google.com \
    --cc=riel@redhat.com \
    --cc=rientjes@google.com \
    --cc=skumar@linux.vnet.ibm.com \
    --cc=xemul@openvz.org \
    --cc=yamamoto@valinux.co.jp \
    /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.