Re: [PATCH 3/5] Memory controller soft limit organize cgroups (v7)

[Balbir Singh <balbir@linux.vnet.ibm.com>]

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-03-23 08:53:14]:

> On Sun, 22 Mar 2009 19:51:05 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > >         if (mem_cgroup_soft_limit_check(mem, &soft_fail_res)) {
> > > 		mem_over_soft_limit =
> > > 			mem_cgroup_from_res_counter(soft_fail_res, res);
> > > 		mem_cgroup_update_tree(mem_over_soft_limit);
> > > 	}
> > > 
> > > Then, we really do softlimit check once in interval.
> > 
> > OK, so the trade-off is - every once per interval,
> > I need to walk up res_counters all over again, hold all locks and
> > check. Like I mentioned earlier, with the current approach I've
> > reduced the overhead significantly for non-users. Earlier I was seeing
> > a small loss in output with reaim, but since I changed
> > res_counter_uncharge to track soft limits, that difference is negligible
> > now.
> > 
> > The issue I see with this approach is that if soft-limits were
> > not enabled, even then we would need to walk up the hierarchy and do
> > tests, where as embedding it in res_counter_charge, one simple check
> > tells us we don't have more to do.
> > 
> Not at all.
> 
> just check softlimit is enabled or not in mem_cgroup_soft_limit_check() by some flag.
>

So far, we don't use flags, the default soft limit is LONGLONG_MAX, if
hierarchy is enabled, we need to check all the way up. The only way we
check over limit is via a comparison. Are you suggesting we cache the
value or save a special flag whenever the soft limit is set to
anything other than LONGLONG_MAX? It is an indication that we are
using soft limits, but we still need to see if we exceed it.

Why are we trying to over optimize this path? Like I mentioned
earlier, the degradation is down to the order of noise. Knuth,
re-learnt several times that "premature optimization is the root of
all evil". If we find an issue with performance, we can definitely go
down the road you are suggesting.
 

-- 
	Balbir

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