Re: [PATCH 0/4] Memory controller soft limit patches (v3)

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

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-03-03 20:50:56]:

> Balbir Singh wrote:
> > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-03-03
> > 08:59:14]:
> >> But, on NUMA, because memcg just checks "usage" and doesn't check
> >> "usage-per-node", there can be memory shortage and this kind of
> >> soft-limit
> >> sounds attractive for me.
> >>
> >
> >
> > Could you please elaborate further on this?
> >
> Try to explain by artificial example..
> .
> Assume a system with 4 nodes, and 1G of memory per node.
> ==
>      Node0 -- 1G
>      Node1 -- 1G
>      Node2 -- 1G
>      Node3 -- 1G
> ==
> And assume there are 3 memory cgroups of following hard-limit.
> ==
>     GroupA -- 1G
>     GroupB -- 0.6G
>     GroupC -- 0.6G
> ==
> If the machine is not-NUMA and 4G SMP, we expect 1.8G of free memory and
> we can assume "global memory shortage" is a rare event.
> 
> But on NUMA, memory usage can be following.
> ==
>      GroupA -- 950M of usage
>      GrouoB -- 550M of usage
>      GroupC -- 550M of usage
> and
>      Node0 -- usage=1G
>      Node1 -- usage=1G
>      Node2 -- usage=50M
>      Node2 -- Usage=0
> ==
> In this case, kswapd will work on Node0, and Node1.
> Softlimit will have chance to work. If the user declares GroupA's softlimit
> is 800M, GroupA will be victim in this case.
>

Yes, GroupA is the victim, but if GroupA has not allocated from a
particular node, we can ensure that we don't reclaim from that node
even while doing soft limit reclaim.
 
> But we have to admit this is hard-to-use scheduling paramter. Almost all
> administrator will not be able to set proper value.
> A useful case I can think of is creating some "victim" group and guard
> other groups from global memory reclaim. I think I need some study about
> how-to-use softlimit. But we'll need this kind of paramater,anyway and
> I don't have onjection to add this kind of scheduling parameter.
> But implementation should be simple at this stage and we should
> find best scheduling algorithm under use-case finally...
> 

Yes and it should be correct and reliable and not based on heuristics
that are hard to prove as correct or even acceptable. Let me work on
the comments so far and refresh the patches.

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