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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 17 Mar 2010, KAMEZAWA Hiroyuki wrote:

> > > 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?  
> It's initalized to inifinite (-1UL).
> 

Ah, that makes sense.

> > In other words, is this the optimal way 
> > to determine how much resident memory and swap that current's memcg is 
> > allowed?
> > 
> I think so.
> 
> It's guaranteed that
> 	mem->res.limit <= mem->memsw.limit
> 
> Then, only when
> 	mem->res.limit + total_swap_pages > mem->memsw.limit
> memsw.limit works.
> 

Ok, I'll use your suggestion and then it can be maintained in 
mm/memcontrol.c for any future updates.

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]