Re: [RFC][PATCH 0/5] memcg softlimit (Another one) v4

[Balbir Singh]

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> [2009-03-12 17:45:44]:

> On Thu, 12 Mar 2009 13:56:46 +0530
> Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote:
> 
> > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> [2009-03-12 14:32:12]:
> > 
> > > On Thu, 12 Mar 2009 10:34:23 +0530
> > > Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote:
> > > 
> > > > Not yet.. you just posted it. I am testing my v5, which I'll post
> > > > soon. I am seeing very good results with v5. I'll test yours later
> > > > today.
> > > > 
> > > 
> > > If "hooks" to usual path doesn't exist and there are no global locks,
> > > I don't have much concern with your version.
> > 
> > Good to know. I think it is always good to have competing patches and
> > then collaborating and getting the best in.
> > 
> > > But 'sorting' seems to be overkill to me.
> > > 
> > 
> > Sorting is very useful, specially if you have many cgroups. Without
> > sorting, how do we select what group to select first.
> > 
> As I explained, if round-robin works well, ordering has no meaning.
> That's just a difference of what is the fairness.
> 
>   1. In your method, recalaim at first from the user which exceeds the most
>      is fair.
>   2. In my method, reclaim from each cgroup in round robin is fair.
> 
> No big issue to users if the kernel policy is fixed.
> Why I take "2" is that the usage of memcg doesn't mean the usage in the zone,
> so, there are no big difference between 1 and 2 on NUMA.
>

Round robin can be bad for soft limits. If an application started up
way ahead of others, but had a small soft limit, we would like
resources to be properly allocated when the second application comes
up. As the number of cgroups increase, selecting the correct cgroup to
reclaim from is going to be a challenge without sorting.

Having said that, I need to do more testing with your patches. 

-- 
	Balbir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/