linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

  reply	other threads:[~2011-05-20 21:49 UTC|newest]

Thread overview: 25+ 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:41 ` [PATCH 1/8] memcg: export zone reclaimable pages KAMEZAWA Hiroyuki
2011-05-20  3:42 ` [PATCH 2/8] memcg: easy check routine for reclaimable KAMEZAWA Hiroyuki
2011-05-20 21:49   ` Andrew Morton
2011-05-20 23:57     ` Hiroyuki Kamezawa
2011-05-20  3:43 ` [PATCH 0/8] memcg: clean up, export swapiness KAMEZAWA Hiroyuki
2011-05-23 17:26   ` Ying Han
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:46 ` [PATCH 6/8] memcg asynchronous memory reclaim interface KAMEZAWA Hiroyuki
2011-05-20 21:49   ` Andrew Morton [this message]
2011-05-20 23:56     ` Hiroyuki Kamezawa
2011-05-23 23:36       ` Ying Han
2011-05-24  0:11         ` KAMEZAWA Hiroyuki
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 21:50   ` Andrew Morton
2011-05-21  0:23     ` Hiroyuki Kamezawa
2011-05-20  3:48 ` [PATCH 8/8] memcg asyncrhouns reclaim workqueue KAMEZAWA Hiroyuki
2011-05-20 21:51   ` Andrew Morton
2011-05-21  0:41     ` Hiroyuki Kamezawa
2011-05-21  1:26       ` Andrew Morton
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

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).