linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: balbir@linux.vnet.ibm.com
Cc: linux-mm@kvack.org, YAMAMOTO Takashi <yamamoto@valinux.co.jp>,
	lizf@cn.fujitsu.com,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Rik van Riel <riel@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 3/4] Memory controller soft limit organize cgroups (v6)
Date: Mon, 16 Mar 2009 17:57:52 +0900	[thread overview]
Message-ID: <20090316175752.50403b00.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <20090316084734.GW16897@balbir.in.ibm.com>

On Mon, 16 Mar 2009 14:17:35 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-03-16 09:21:26]:

> > Maybe code like this is good.
> > ==
> >  if (need_softlimit_check(mem)) {
> >      softlimit_res = res_counter_check_under_softlimit(&mem->res);
> >      if (softlimit_res) {
> >         struct mem_cgroup *mem = mem_cgroup_from_cont(softlimit_res);
> >         update_tree()....      
> >      }
> >  }
> > ==
> 
> An additional if is the problem?
My point is "check condition but the result is not used always" is ugly.

> We do all the checks under a lock we
> already hold. I ran aim9, new_dbase, dbase, compute and shared tests
> to make sure that there is no degradation. I've not seen anything
> noticable so far.
> 
ya, maybe. How about unix-bench exec test ?
(it's one of the worst application for memcg ;)

> > 
> > *And* what is important here is "need_softlimit_check(mem)".
> > As Andrew said, there may be something reasonable rather than using tick.
> > So, adding "mem_cgroup_need_softlimit_check(mem)" and improving what it checks
> > makes sense for development.
> > 
> 
> OK, that is a good abstraction, but scanning as a metric does not guarantee
> anything. It is harder to come up with better heuristics with scan
> rate than to come up with something time based. I am open to
> suggestions for something reliable though.
> 
I think making this easy-to-be-modified will help people other than us.
The memory-management algorithm is very difficult but people tend to try
their own new logic to improve overall performance.

Refactoring to make "modification of algorithm" easy makes sense for Linux, OSS.
We're not only people to modify memcontrol.c

So, I think some abstraction is good.

Thanks,
-Kame

--
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>

  reply	other threads:[~2009-03-16  8:59 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-14 17:30 [PATCH 0/4] Memory controller soft limit patches (v6) Balbir Singh
2009-03-14 17:30 ` [PATCH 1/4] Memory controller soft limit documentation (v6) Balbir Singh
2009-03-14 17:30 ` [PATCH 2/4] Memory controller soft limit interface (v6) Balbir Singh
2009-03-14 17:31 ` [PATCH 3/4] Memory controller soft limit organize cgroups (v6) Balbir Singh
2009-03-16  0:21   ` KAMEZAWA Hiroyuki
2009-03-16  8:47     ` Balbir Singh
2009-03-16  8:57       ` KAMEZAWA Hiroyuki [this message]
2009-03-14 17:31 ` [PATCH 4/4] Memory controller soft limit reclaim on contention (v6) Balbir Singh
2009-03-16  0:52   ` KAMEZAWA Hiroyuki
2009-03-16  8:35     ` Balbir Singh
2009-03-16  8:49       ` KAMEZAWA Hiroyuki
2009-03-16  9:03         ` KAMEZAWA Hiroyuki
2009-03-16  9:10           ` Balbir Singh
2009-03-16 11:10             ` KAMEZAWA Hiroyuki
2009-03-16 11:38               ` Balbir Singh
2009-03-16 11:58                 ` KAMEZAWA Hiroyuki
2009-03-16 12:19                   ` Balbir Singh
2009-03-17  3:47                     ` KAMEZAWA Hiroyuki
2009-03-17  4:40                       ` Balbir Singh
2009-03-17  4:47                         ` KAMEZAWA Hiroyuki
2009-03-17  4:58                           ` Balbir Singh
2009-03-17  5:17                             ` KAMEZAWA Hiroyuki
2009-03-17  5:55                               ` Balbir Singh
2009-03-17  6:00                                 ` KAMEZAWA Hiroyuki
2009-03-17  6:22                                   ` Balbir Singh
2009-03-17  6:30                                     ` KAMEZAWA Hiroyuki
2009-03-17  6:59                                       ` Balbir Singh
2009-03-18  0:07       ` KAMEZAWA Hiroyuki
2009-03-18  4:14         ` 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=20090316175752.50403b00.kamezawa.hiroyu@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=riel@redhat.com \
    --cc=yamamoto@valinux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox