From: Andrew Morton <akpm@linux-foundation.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"nishimura@mxp.nes.nec.co.jp" <nishimura@mxp.nes.nec.co.jp>,
"balbir@linux.vnet.ibm.com" <balbir@linux.vnet.ibm.com>,
Ying Han <yinghan@google.com>,
hannes@cmpxchg.org, Michal Hocko <mhocko@suse.cz>
Subject: Re: [PATCH 6/8] memcg asynchronous memory reclaim interface
Date: Fri, 20 May 2011 14:49:35 -0700 [thread overview]
Message-ID: <20110520144935.3bfdb2e2.akpm@linux-foundation.org> (raw)
In-Reply-To: <20110520124636.45c26cfa.kamezawa.hiroyu@jp.fujitsu.com>
On Fri, 20 May 2011 12:46:36 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> This patch adds a logic to keep usage margin to the limit in asynchronous way.
> When the usage over some threshould (determined automatically), asynchronous
> memory reclaim runs and shrink memory to limit - MEMCG_ASYNC_STOP_MARGIN.
>
> By this, there will be no difference in total amount of usage of cpu to
> scan the LRU
This is not true if "don't writepage at all (revisit this when
dirty_ratio comes.)" is true. Skipping over dirty pages can cause
larger amounts of CPU consumption.
> but we'll have a chance to make use of wait time of applications
> for freeing memory. For example, when an application read a file or socket,
> to fill the newly alloated memory, it needs wait. Async reclaim can make use
> of that time and give a chance to reduce latency by background works.
>
> This patch only includes required hooks to trigger async reclaim and user interfaces.
> Core logics will be in the following patches.
>
>
> ...
>
> /*
> + * For example, with transparent hugepages, memory reclaim scan at hitting
> + * limit can very long as to reclaim HPAGE_SIZE of memory. This increases
> + * latency of page fault and may cause fallback. At usual page allocation,
> + * we'll see some (shorter) latency, too. To reduce latency, it's appreciated
> + * to free memory in background to make margin to the limit. This consumes
> + * cpu but we'll have a chance to make use of wait time of applications
> + * (read disk etc..) by asynchronous reclaim.
> + *
> + * This async reclaim tries to reclaim HPAGE_SIZE * 2 of pages when margin
> + * to the limit is smaller than HPAGE_SIZE * 2. This will be enabled
> + * automatically when the limit is set and it's greater than the threshold.
> + */
> +#if HPAGE_SIZE != PAGE_SIZE
> +#define MEMCG_ASYNC_LIMIT_THRESH (HPAGE_SIZE * 64)
> +#define MEMCG_ASYNC_MARGIN (HPAGE_SIZE * 4)
> +#else /* make the margin as 4M bytes */
> +#define MEMCG_ASYNC_LIMIT_THRESH (128 * 1024 * 1024)
> +#define MEMCG_ASYNC_MARGIN (8 * 1024 * 1024)
> +#endif
Document them, please. How are they used, what are their units.
> +static void mem_cgroup_may_async_reclaim(struct mem_cgroup *mem);
> +
> +/*
> * The memory controller data structure. The memory controller controls both
> * page cache and RSS per cgroup. We would eventually like to provide
> * statistics based on the statistics developed by Rik Van Riel for clock-pro,
> @@ -278,6 +303,12 @@ struct mem_cgroup {
> */
> unsigned long move_charge_at_immigrate;
> /*
> + * Checks for async reclaim.
> + */
> + unsigned long async_flags;
> +#define AUTO_ASYNC_ENABLED (0)
> +#define USE_AUTO_ASYNC (1)
These are really confusing. I looked at the implementation and at the
documentation file and I'm still scratching my head. I can't work out
why they exist. With the amount of effort I put into it ;)
Also, AUTO_ASYNC_ENABLED and USE_AUTO_ASYNC have practically the same
meaning, which doesn't help things.
Some careful description at this place in the code might help clear
things up.
Perhaps s/USE_AUTO_ASYNC/AUTO_ASYNC_IN_USE/ is what you meant.
>
> ...
>
> +static void mem_cgroup_may_async_reclaim(struct mem_cgroup *mem)
> +{
> + if (!test_bit(USE_AUTO_ASYNC, &mem->async_flags))
> + return;
> + if (res_counter_margin(&mem->res) <= MEMCG_ASYNC_MARGIN) {
> + /* Fill here */
> + }
> +}
I'd expect a function called foo_may_bar() to return a bool.
But given the lack of documentation and no-op implementation, I have o
idea what's happening here!
>
> ...
>
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"nishimura@mxp.nes.nec.co.jp" <nishimura@mxp.nes.nec.co.jp>,
"balbir@linux.vnet.ibm.com" <balbir@linux.vnet.ibm.com>,
Ying Han <yinghan@google.com>,
hannes@cmpxchg.org, Michal Hocko <mhocko@suse.cz>
Subject: Re: [PATCH 6/8] memcg asynchronous memory reclaim interface
Date: Fri, 20 May 2011 14:49:35 -0700 [thread overview]
Message-ID: <20110520144935.3bfdb2e2.akpm@linux-foundation.org> (raw)
In-Reply-To: <20110520124636.45c26cfa.kamezawa.hiroyu@jp.fujitsu.com>
On Fri, 20 May 2011 12:46:36 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> This patch adds a logic to keep usage margin to the limit in asynchronous way.
> When the usage over some threshould (determined automatically), asynchronous
> memory reclaim runs and shrink memory to limit - MEMCG_ASYNC_STOP_MARGIN.
>
> By this, there will be no difference in total amount of usage of cpu to
> scan the LRU
This is not true if "don't writepage at all (revisit this when
dirty_ratio comes.)" is true. Skipping over dirty pages can cause
larger amounts of CPU consumption.
> but we'll have a chance to make use of wait time of applications
> for freeing memory. For example, when an application read a file or socket,
> to fill the newly alloated memory, it needs wait. Async reclaim can make use
> of that time and give a chance to reduce latency by background works.
>
> This patch only includes required hooks to trigger async reclaim and user interfaces.
> Core logics will be in the following patches.
>
>
> ...
>
> /*
> + * For example, with transparent hugepages, memory reclaim scan at hitting
> + * limit can very long as to reclaim HPAGE_SIZE of memory. This increases
> + * latency of page fault and may cause fallback. At usual page allocation,
> + * we'll see some (shorter) latency, too. To reduce latency, it's appreciated
> + * to free memory in background to make margin to the limit. This consumes
> + * cpu but we'll have a chance to make use of wait time of applications
> + * (read disk etc..) by asynchronous reclaim.
> + *
> + * This async reclaim tries to reclaim HPAGE_SIZE * 2 of pages when margin
> + * to the limit is smaller than HPAGE_SIZE * 2. This will be enabled
> + * automatically when the limit is set and it's greater than the threshold.
> + */
> +#if HPAGE_SIZE != PAGE_SIZE
> +#define MEMCG_ASYNC_LIMIT_THRESH (HPAGE_SIZE * 64)
> +#define MEMCG_ASYNC_MARGIN (HPAGE_SIZE * 4)
> +#else /* make the margin as 4M bytes */
> +#define MEMCG_ASYNC_LIMIT_THRESH (128 * 1024 * 1024)
> +#define MEMCG_ASYNC_MARGIN (8 * 1024 * 1024)
> +#endif
Document them, please. How are they used, what are their units.
> +static void mem_cgroup_may_async_reclaim(struct mem_cgroup *mem);
> +
> +/*
> * The memory controller data structure. The memory controller controls both
> * page cache and RSS per cgroup. We would eventually like to provide
> * statistics based on the statistics developed by Rik Van Riel for clock-pro,
> @@ -278,6 +303,12 @@ struct mem_cgroup {
> */
> unsigned long move_charge_at_immigrate;
> /*
> + * Checks for async reclaim.
> + */
> + unsigned long async_flags;
> +#define AUTO_ASYNC_ENABLED (0)
> +#define USE_AUTO_ASYNC (1)
These are really confusing. I looked at the implementation and at the
documentation file and I'm still scratching my head. I can't work out
why they exist. With the amount of effort I put into it ;)
Also, AUTO_ASYNC_ENABLED and USE_AUTO_ASYNC have practically the same
meaning, which doesn't help things.
Some careful description at this place in the code might help clear
things up.
Perhaps s/USE_AUTO_ASYNC/AUTO_ASYNC_IN_USE/ is what you meant.
>
> ...
>
> +static void mem_cgroup_may_async_reclaim(struct mem_cgroup *mem)
> +{
> + if (!test_bit(USE_AUTO_ASYNC, &mem->async_flags))
> + return;
> + if (res_counter_margin(&mem->res) <= MEMCG_ASYNC_MARGIN) {
> + /* Fill here */
> + }
> +}
I'd expect a function called foo_may_bar() to return a bool.
But given the lack of documentation and no-op implementation, I have o
idea what's happening here!
>
> ...
>
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-05-20 21:49 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-20 3:37 [PATCH 0/8] memcg async reclaim v2 KAMEZAWA Hiroyuki
2011-05-20 3:37 ` KAMEZAWA Hiroyuki
2011-05-20 3:41 ` [PATCH 1/8] memcg: export zone reclaimable pages KAMEZAWA Hiroyuki
2011-05-20 3:41 ` KAMEZAWA Hiroyuki
2011-05-20 3:42 ` [PATCH 2/8] memcg: easy check routine for reclaimable KAMEZAWA Hiroyuki
2011-05-20 3:42 ` KAMEZAWA Hiroyuki
2011-05-20 21:49 ` Andrew Morton
2011-05-20 21:49 ` Andrew Morton
2011-05-20 23:57 ` Hiroyuki Kamezawa
2011-05-20 23:57 ` Hiroyuki Kamezawa
2011-05-20 3:43 ` [PATCH 0/8] memcg: clean up, export swapiness KAMEZAWA Hiroyuki
2011-05-20 3:43 ` KAMEZAWA Hiroyuki
2011-05-23 17:26 ` Ying Han
2011-05-23 17:26 ` Ying Han
2011-05-23 23:55 ` KAMEZAWA Hiroyuki
2011-05-23 23:55 ` KAMEZAWA Hiroyuki
2011-05-20 3:44 ` [PATCH 4/8] memcg: export release victim KAMEZAWA Hiroyuki
2011-05-20 3:44 ` KAMEZAWA Hiroyuki
2011-05-20 3:46 ` [PATCH 6/8] memcg asynchronous memory reclaim interface KAMEZAWA Hiroyuki
2011-05-20 3:46 ` KAMEZAWA Hiroyuki
2011-05-20 21:49 ` Andrew Morton [this message]
2011-05-20 21:49 ` Andrew Morton
2011-05-20 23:56 ` Hiroyuki Kamezawa
2011-05-20 23:56 ` Hiroyuki Kamezawa
2011-05-23 23:36 ` Ying Han
2011-05-23 23:36 ` Ying Han
2011-05-24 0:11 ` KAMEZAWA Hiroyuki
2011-05-24 0:11 ` KAMEZAWA Hiroyuki
2011-05-24 0:26 ` Ying Han
2011-05-24 0:26 ` Ying Han
2011-05-20 3:47 ` [PATCH 7/8] memcg static scan reclaim for asyncrhonous reclaim KAMEZAWA Hiroyuki
2011-05-20 3:47 ` KAMEZAWA Hiroyuki
2011-05-20 21:50 ` Andrew Morton
2011-05-20 21:50 ` Andrew Morton
2011-05-21 0:23 ` Hiroyuki Kamezawa
2011-05-21 0:23 ` Hiroyuki Kamezawa
2011-05-20 3:48 ` [PATCH 8/8] memcg asyncrhouns reclaim workqueue KAMEZAWA Hiroyuki
2011-05-20 3:48 ` KAMEZAWA Hiroyuki
2011-05-20 21:51 ` Andrew Morton
2011-05-20 21:51 ` Andrew Morton
2011-05-21 0:41 ` Hiroyuki Kamezawa
2011-05-21 0:41 ` Hiroyuki Kamezawa
2011-05-21 1:26 ` Andrew Morton
2011-05-21 1:26 ` Andrew Morton
2011-05-23 0:25 ` KAMEZAWA Hiroyuki
2011-05-23 0:25 ` KAMEZAWA Hiroyuki
2011-05-25 5:51 ` Ying Han
[not found] ` <BANLkTimd0CAqoAnuGz7WvKsbwphJxo0eZQ@mail.gmail.com>
2011-05-24 0:19 ` [PATCH 0/8] memcg async reclaim v2 KAMEZAWA Hiroyuki
2011-05-24 0:19 ` 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=20110520144935.3bfdb2e2.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=nishimura@mxp.nes.nec.co.jp \
--cc=yinghan@google.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.