Re: [patch 05/10 -mm v3] oom: badness heuristic rewrite

[David Rientjes <rientjes@google.com>]

On Fri, 12 Mar 2010, KAMEZAWA Hiroyuki wrote:

> A small concern here.
> 
> +u64 mem_cgroup_get_limit(struct mem_cgroup *memcg)
> +{
> +       return res_counter_read_u64(&memcg->memsw, RES_LIMIT);
> +}
> 
> Because memory cgroup has 2 limit controls as "memory" and "memory+swap",
> a user may set only "memory" limitation. (Especially on swapless system.)
> Then, memcg->memsw limit can be infinite in some situation.
> 
> So, how about this ? (just an idea after breif thinking..)
> 
> u64 mem_cgroup_get_memsw_limit(struct mem_cgroup *memcg)
> {
> 	u64 memlimit, memswlimit;
> 
> 	memlimit = res_counter_read_u64(&memcg->res, RES_LIMIT);
> 	memswlimit = res_counter_read_u64(&memcg->memsw, RES_LIMIT);
> 	if (memlimit + total_swap_pages > memswlimit)
> 		return memswlimit;
> 	return memlimit + total_swap_pages;
> }
> 

I definitely trust your judgment when it comes to memcg, so this is how I 
implemented it for v4.

Is the memcg->memsw RES_LIMIT not initialized to zero for swapless systems 
or when users don't set a value?  In other words, is this the optimal way 
to determine how much resident memory and swap that current's memcg is 
allowed?

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