From: Balbir Singh <balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: KAMEZAWA Hiroyuki
<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
Cc: Rik van Riel <riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"yamamoto-jCdQPDEk3idL9jVzuh4AOg@public.gmane.org"
<yamamoto-jCdQPDEk3idL9jVzuh4AOg@public.gmane.org>,
"linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org"
<linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
"containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org"
<containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org
Subject: Re: [RFC][for -mm] memory controller enhancements for reclaiming take2 [5/8] throttling simultaneous callers of try_to_free_mem_cgroup_pages
Date: Tue, 04 Dec 2007 18:57:22 +0530 [thread overview]
Message-ID: <475555BA.7070805@linux.vnet.ibm.com> (raw)
In-Reply-To: <20071204103332.ad4cf9b5.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
KAMEZAWA Hiroyuki wrote:
> On Mon, 3 Dec 2007 09:24:18 -0500
> Rik van Riel <riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
>> On Mon, 3 Dec 2007 18:39:21 +0900
>> KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> wrote:
>>
>>> Add throttling direct reclaim.
>>>
>>> Trying heavy workload under memory controller, you'll see too much
>>> iowait and system seems heavy. (This is not good.... memory controller
>>> is usually used for isolating system workload)
>>> And too much memory are reclaimed.
>>>
>>> This patch adds throttling function for direct reclaim.
>>> Currently, num_online_cpus/(4) + 1 threads can do direct memory reclaim
>>> under memory controller.
>> The same problems are true of global reclaim.
>>
>> Now that we're discussing this RFC anyway, I wonder if we
>> should think about moving this restriction to the global
>> reclaim level...
>>
> Hmm, I agree to some extent.
> I'd like to add the same level of parameters to memory controller AMAP.
>
The CKRM memory controller had the following parameters for throttling
Watermarks
shrink_at
shrink_to
and
num_shrinks
shrink_interval
Number of times shrink can be called in a shrink_interval.
> But, IMHO, there are differences basically.
>
> Memory controller's reclaim is much heavier than global LRU because of
> increasing footprint , the number of atomic ops....
> And memory controller's reclaim policy is simpler than global because
> it is not kicked by memory shortage and almost all gfk_mask is GFP_HIGHUSER_MOVABLE
> and order is always 0.
>
> I think starting from throttling memory controller is not so bad because
> it's heavy and it's simple. The benefit of this throttoling is clearer than
> globals.
>
I think global throttling is good as well, sometimes under heavy load I
find several tasks stuck in reclaim. I suspect throttling them and avoid
this scenario. May be worth experimenting an thinking about it deserves
more discussion.
> Adding this kind of controls to global memory allocator/LRU may cause
> unexpected slow down in application's response time. High-response application
> users may dislike this. We may need another gfp_flag or sysctl to allow
> throttling in global.
> For memory controller, the user sets its memory limitation by himself. He can
> adjust parameters and the workload. So, I think this throttoling is not so
> problematic in memory controller as global.
>
> Of course, we can export "do throttoling or not" control in cgroup interface.
>
I think we should export the interface.
>
> Thanks,
> -Kame
>
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
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: Rik van Riel <riel@redhat.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"containers@lists.osdl.org" <containers@lists.osdl.org>,
Andrew Morton <akpm@linux-foundation.org>,
"yamamoto@valinux.co.jp" <yamamoto@valinux.co.jp>,
xemul@openvz.org
Subject: Re: [RFC][for -mm] memory controller enhancements for reclaiming take2 [5/8] throttling simultaneous callers of try_to_free_mem_cgroup_pages
Date: Tue, 04 Dec 2007 18:57:22 +0530 [thread overview]
Message-ID: <475555BA.7070805@linux.vnet.ibm.com> (raw)
In-Reply-To: <20071204103332.ad4cf9b5.kamezawa.hiroyu@jp.fujitsu.com>
KAMEZAWA Hiroyuki wrote:
> On Mon, 3 Dec 2007 09:24:18 -0500
> Rik van Riel <riel@redhat.com> wrote:
>
>> On Mon, 3 Dec 2007 18:39:21 +0900
>> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>>
>>> Add throttling direct reclaim.
>>>
>>> Trying heavy workload under memory controller, you'll see too much
>>> iowait and system seems heavy. (This is not good.... memory controller
>>> is usually used for isolating system workload)
>>> And too much memory are reclaimed.
>>>
>>> This patch adds throttling function for direct reclaim.
>>> Currently, num_online_cpus/(4) + 1 threads can do direct memory reclaim
>>> under memory controller.
>> The same problems are true of global reclaim.
>>
>> Now that we're discussing this RFC anyway, I wonder if we
>> should think about moving this restriction to the global
>> reclaim level...
>>
> Hmm, I agree to some extent.
> I'd like to add the same level of parameters to memory controller AMAP.
>
The CKRM memory controller had the following parameters for throttling
Watermarks
shrink_at
shrink_to
and
num_shrinks
shrink_interval
Number of times shrink can be called in a shrink_interval.
> But, IMHO, there are differences basically.
>
> Memory controller's reclaim is much heavier than global LRU because of
> increasing footprint , the number of atomic ops....
> And memory controller's reclaim policy is simpler than global because
> it is not kicked by memory shortage and almost all gfk_mask is GFP_HIGHUSER_MOVABLE
> and order is always 0.
>
> I think starting from throttling memory controller is not so bad because
> it's heavy and it's simple. The benefit of this throttoling is clearer than
> globals.
>
I think global throttling is good as well, sometimes under heavy load I
find several tasks stuck in reclaim. I suspect throttling them and avoid
this scenario. May be worth experimenting an thinking about it deserves
more discussion.
> Adding this kind of controls to global memory allocator/LRU may cause
> unexpected slow down in application's response time. High-response application
> users may dislike this. We may need another gfp_flag or sysctl to allow
> throttling in global.
> For memory controller, the user sets its memory limitation by himself. He can
> adjust parameters and the workload. So, I think this throttoling is not so
> problematic in memory controller as global.
>
> Of course, we can export "do throttoling or not" control in cgroup interface.
>
I think we should export the interface.
>
> Thanks,
> -Kame
>
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
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:[~2007-12-04 13:27 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-03 9:33 [RFC][for -mm] memory controller enhancements for reclaiming take2 [0/8] introduction KAMEZAWA Hiroyuki
2007-12-03 9:33 ` KAMEZAWA Hiroyuki
[not found] ` <20071203183355.0061ddeb.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2007-12-03 9:35 ` [RFC][for -mm] memory controller enhancements for reclaiming take2 [1/8] clean up : remove unused variable KAMEZAWA Hiroyuki
2007-12-03 9:35 ` KAMEZAWA Hiroyuki
[not found] ` <20071203183537.059262e9.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2007-12-04 15:55 ` Balbir Singh
2007-12-04 15:55 ` Balbir Singh
2007-12-03 9:36 ` [RFC][for -mm] memory controller enhancements for reclaiming take2 [2/8] add BUG_ON() in mem_cgroup_zoneinfo KAMEZAWA Hiroyuki
2007-12-03 9:36 ` KAMEZAWA Hiroyuki
[not found] ` <20071203183639.48a4b1f3.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2007-12-04 16:01 ` Balbir Singh
2007-12-04 16:01 ` Balbir Singh
2007-12-03 9:37 ` [RFC][for -mm] memory controller enhancements for reclaiming take2 [3/8] define free_mem_cgroup_per_zone_info KAMEZAWA Hiroyuki
2007-12-03 9:37 ` KAMEZAWA Hiroyuki
[not found] ` <20071203183719.b929cb92.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2007-12-04 16:32 ` Balbir Singh
2007-12-04 16:32 ` Balbir Singh
2007-12-03 9:38 ` [RFC][for -mm] memory controller enhancements for reclaiming take2 [4/8] possible race fix in res_counter KAMEZAWA Hiroyuki
2007-12-03 9:38 ` KAMEZAWA Hiroyuki
[not found] ` <20071203183809.4b83397c.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2007-12-04 19:02 ` Balbir Singh
2007-12-04 19:02 ` Balbir Singh
2007-12-03 9:39 ` [RFC][for -mm] memory controller enhancements for reclaiming take2 [5/8] throttling simultaneous callers of try_to_free_mem_cgroup_pages KAMEZAWA Hiroyuki
2007-12-03 9:39 ` KAMEZAWA Hiroyuki
[not found] ` <20071203183921.72005b21.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2007-12-03 14:24 ` Rik van Riel
2007-12-03 14:24 ` Rik van Riel
[not found] ` <20071203092418.58631593-Fuq27k0DHcCSkoNiqTzCLQ@public.gmane.org>
2007-12-04 1:33 ` KAMEZAWA Hiroyuki
2007-12-04 1:33 ` KAMEZAWA Hiroyuki
[not found] ` <20071204103332.ad4cf9b5.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2007-12-04 13:27 ` Balbir Singh [this message]
2007-12-04 13:27 ` Balbir Singh
[not found] ` <475555BA.7070805-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2007-12-05 0:26 ` KAMEZAWA Hiroyuki
2007-12-05 0:26 ` KAMEZAWA Hiroyuki
2007-12-03 9:41 ` [RFC][for -mm] memory controller enhancements for reclaiming take2 [6/8] high_low watermark for res_counter KAMEZAWA Hiroyuki
2007-12-03 9:41 ` KAMEZAWA Hiroyuki
2007-12-03 9:42 ` [RFC][for -mm] memory controller enhancements for reclaiming take2 [7/8] bacground reclaim for memory controller KAMEZAWA Hiroyuki
2007-12-03 9:42 ` KAMEZAWA Hiroyuki
[not found] ` <20071203184244.200faee8.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2007-12-04 3:07 ` YAMAMOTO Takashi
2007-12-04 3:07 ` YAMAMOTO Takashi
[not found] ` <20071204030756.25A971D0B8F-Pcsii4f/SVk@public.gmane.org>
2007-12-04 3:18 ` KAMEZAWA Hiroyuki
2007-12-04 3:18 ` KAMEZAWA Hiroyuki
[not found] ` <20071204121856.910afa40.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2007-12-04 3:31 ` YAMAMOTO Takashi
2007-12-04 3:31 ` YAMAMOTO Takashi
2007-12-03 9:45 ` [RFC][for -mm] memory controller enhancements for reclaiming take2 [8/8] wake up waiters at unchage KAMEZAWA Hiroyuki
2007-12-03 9:45 ` KAMEZAWA Hiroyuki
2007-12-04 6:46 ` [RFC][for -mm] memory controller enhancements for reclaiming take2 [0/8] introduction KAMEZAWA Hiroyuki
2007-12-04 6:46 ` KAMEZAWA Hiroyuki
2007-12-04 14:25 ` Balbir Singh
2007-12-04 14:25 ` Balbir Singh
[not found] ` <47556341.4090101-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2007-12-05 0:44 ` KAMEZAWA Hiroyuki
2007-12-05 0:44 ` 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=475555BA.7070805@linux.vnet.ibm.com \
--to=balbir-23vcf4htsmix0ybbhkvfkdbpr1lh4cv8@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=yamamoto-jCdQPDEk3idL9jVzuh4AOg@public.gmane.org \
/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.