From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
nishimura@mxp.nes.nec.co.jp, menage@google.com
Subject: Re: [RFC][PATCH 1/6] memcg: free all at rmdir
Date: Thu, 13 Nov 2008 06:50:40 +0530 [thread overview]
Message-ID: <491B80E8.4090107@linux.vnet.ibm.com> (raw)
In-Reply-To: <20081113101344.6882c209.kamezawa.hiroyu@jp.fujitsu.com>
KAMEZAWA Hiroyuki wrote:
> On Wed, 12 Nov 2008 16:07:58 -0800
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
>> On Wed, 12 Nov 2008 12:26:56 +0900
>> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>>
>>> +5.1 on_rmdir
>>> +set behavior of memcg at rmdir (Removing cgroup) default is "drop".
>>> +
>>> +5.1.1 drop
>>> + #echo on_rmdir drop > memory.attribute
>>> + This is default. All pages on the memcg will be freed.
>>> + If pages are locked or too busy, they will be moved up to the parent.
>>> + Useful when you want to drop (large) page caches used in this memcg.
>>> + But some of in-use page cache can be dropped by this.
>>> +
>>> +5.1.2 keep
>>> + #echo on_rmdir keep > memory.attribute
>>> + All pages on the memcg will be moved to its parent.
>>> + Useful when you don't want to drop page caches used in this memcg.
>>> + You can keep page caches from some library or DB accessed by this
>>> + memcg on memory.
>> Would it not be more useful to implement a per-memcg version of
>> /proc/sys/vm/drop_caches? (One without drop_caches' locking bug,
>> hopefully).
>>
>> If we do this then we can make the above "keep" behaviour non-optional,
>> and the operator gets to choose whether or not to drop the caches
>> before doing the rmdir.
>>
>> Plus, we get a new per-memcg drop_caches capability. And it's a nicer
>> interface, and it doesn't have the obvious races which on_rmdir has,
>> etc.
>>
>> hm?
>>
> In my plan, I'll add
>
> memory.shrink_usage interface to do and allows
>
> #echo 0M > memory.shrink_memory_usage
> (you may swap tasks out if there is task..)
>
> to drop pages.
>
So, shrink_memory_usage is just for dropping caches? I don't understand the part
about swap tasks out.
> Balbir, how do you think ? I've already removed "force_empty".
Have you? Won't that go against API/ABI compatibility guidelines. I would
recommend cc'ing linux-api as well. Sorry, I missed the patch that removes
force_empty. Me culpa.
--
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: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
nishimura@mxp.nes.nec.co.jp, menage@google.com
Subject: Re: [RFC][PATCH 1/6] memcg: free all at rmdir
Date: Thu, 13 Nov 2008 06:50:40 +0530 [thread overview]
Message-ID: <491B80E8.4090107@linux.vnet.ibm.com> (raw)
In-Reply-To: <20081113101344.6882c209.kamezawa.hiroyu@jp.fujitsu.com>
KAMEZAWA Hiroyuki wrote:
> On Wed, 12 Nov 2008 16:07:58 -0800
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
>> On Wed, 12 Nov 2008 12:26:56 +0900
>> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>>
>>> +5.1 on_rmdir
>>> +set behavior of memcg at rmdir (Removing cgroup) default is "drop".
>>> +
>>> +5.1.1 drop
>>> + #echo on_rmdir drop > memory.attribute
>>> + This is default. All pages on the memcg will be freed.
>>> + If pages are locked or too busy, they will be moved up to the parent.
>>> + Useful when you want to drop (large) page caches used in this memcg.
>>> + But some of in-use page cache can be dropped by this.
>>> +
>>> +5.1.2 keep
>>> + #echo on_rmdir keep > memory.attribute
>>> + All pages on the memcg will be moved to its parent.
>>> + Useful when you don't want to drop page caches used in this memcg.
>>> + You can keep page caches from some library or DB accessed by this
>>> + memcg on memory.
>> Would it not be more useful to implement a per-memcg version of
>> /proc/sys/vm/drop_caches? (One without drop_caches' locking bug,
>> hopefully).
>>
>> If we do this then we can make the above "keep" behaviour non-optional,
>> and the operator gets to choose whether or not to drop the caches
>> before doing the rmdir.
>>
>> Plus, we get a new per-memcg drop_caches capability. And it's a nicer
>> interface, and it doesn't have the obvious races which on_rmdir has,
>> etc.
>>
>> hm?
>>
> In my plan, I'll add
>
> memory.shrink_usage interface to do and allows
>
> #echo 0M > memory.shrink_memory_usage
> (you may swap tasks out if there is task..)
>
> to drop pages.
>
So, shrink_memory_usage is just for dropping caches? I don't understand the part
about swap tasks out.
> Balbir, how do you think ? I've already removed "force_empty".
Have you? Won't that go against API/ABI compatibility guidelines. I would
recommend cc'ing linux-api as well. Sorry, I missed the patch that removes
force_empty. Me culpa.
--
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>
next prev parent reply other threads:[~2008-11-13 1:20 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-12 3:26 [RFC][PATCH 0/6] memcg updates (12/Nov/2008) KAMEZAWA Hiroyuki
2008-11-12 3:26 ` KAMEZAWA Hiroyuki
2008-11-12 3:26 ` [RFC][PATCH 1/6] memcg: free all at rmdir KAMEZAWA Hiroyuki
2008-11-12 3:26 ` KAMEZAWA Hiroyuki
2008-11-12 6:07 ` KAMEZAWA Hiroyuki
2008-11-12 6:07 ` KAMEZAWA Hiroyuki
2008-11-13 0:07 ` Andrew Morton
2008-11-13 0:07 ` Andrew Morton
2008-11-13 0:23 ` Balbir Singh
2008-11-13 0:23 ` Balbir Singh
2008-11-13 0:46 ` Andrew Morton
2008-11-13 0:46 ` Andrew Morton
2008-11-13 0:48 ` Balbir Singh
2008-11-13 0:48 ` Balbir Singh
2008-11-13 1:04 ` Andrew Morton
2008-11-13 1:04 ` Andrew Morton
2008-11-13 1:17 ` Balbir Singh
2008-11-13 1:17 ` Balbir Singh
2008-11-13 2:30 ` KAMEZAWA Hiroyuki
2008-11-13 2:30 ` KAMEZAWA Hiroyuki
2008-11-13 1:13 ` KAMEZAWA Hiroyuki
2008-11-13 1:13 ` KAMEZAWA Hiroyuki
2008-11-13 1:20 ` Balbir Singh [this message]
2008-11-13 1:20 ` Balbir Singh
2008-11-13 1:27 ` KAMEZAWA Hiroyuki
2008-11-13 1:27 ` KAMEZAWA Hiroyuki
2008-11-13 2:49 ` KAMEZAWA Hiroyuki
2008-11-13 2:49 ` KAMEZAWA Hiroyuki
2008-11-13 3:14 ` Balbir Singh
2008-11-13 3:14 ` Balbir Singh
2008-11-13 3:22 ` KAMEZAWA Hiroyuki
2008-11-13 3:22 ` KAMEZAWA Hiroyuki
2008-11-13 3:27 ` Balbir Singh
2008-11-13 3:27 ` Balbir Singh
2008-11-13 3:38 ` KAMEZAWA Hiroyuki
2008-11-13 3:38 ` KAMEZAWA Hiroyuki
2008-11-12 3:27 ` [RFC][PATCH 2/6] memcg: account swapcache KAMEZAWA Hiroyuki
2008-11-12 3:27 ` KAMEZAWA Hiroyuki
2008-11-12 3:28 ` [RFC][PATCH 3/6] memcg: mem+swap controller kconfig KAMEZAWA Hiroyuki
2008-11-12 3:28 ` KAMEZAWA Hiroyuki
2008-11-12 3:29 ` [RFC][PATCH 4/6] memcg: swap cgroup for remembering account KAMEZAWA Hiroyuki
2008-11-12 3:29 ` KAMEZAWA Hiroyuki
2008-11-12 4:17 ` Daisuke Nishimura
2008-11-12 4:17 ` Daisuke Nishimura
2008-11-12 4:22 ` KAMEZAWA Hiroyuki
2008-11-12 4:22 ` KAMEZAWA Hiroyuki
2008-11-12 3:30 ` [RFC][PATCH 5/6] memcg: mem+swap controller KAMEZAWA Hiroyuki
2008-11-12 3:30 ` KAMEZAWA Hiroyuki
2008-11-12 3:32 ` [RFC][PATCH 6/6] memcg: synchronized LRU KAMEZAWA Hiroyuki
2008-11-12 3:32 ` KAMEZAWA Hiroyuki
2008-11-12 3:33 ` [RFC][PATCH 0/6] memcg updates (12/Nov/2008) KAMEZAWA Hiroyuki
2008-11-12 3:33 ` KAMEZAWA Hiroyuki
2008-11-12 4:00 ` Balbir Singh
2008-11-12 4:00 ` 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=491B80E8.4090107@linux.vnet.ibm.com \
--to=balbir@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=menage@google.com \
--cc=nishimura@mxp.nes.nec.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.