All of lore.kernel.org
 help / color / mirror / Atom feed
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>

  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.