Re: [PATCH] memcg: implement low limits

From: Michal Hocko
Date: Thu Feb 28 2013 - 08:02:50 EST

On Thu 28-02-13 15:13:15, Roman Gushchin wrote:
> 27.02.2013, 20:14, "Michal Hocko" <mhocko@xxxxxxx>:
> > On Wed 27-02-13 14:39:36, Roman Gushchin wrote:
> >>  2) cgroup's prioritization during global reclaim,
> >
> > Yes, group priorities sound like a useful feature not just for the
> > reclaim I would like it for oom selection as well.
> > I think that we shouldn't use any kind of limit for this task, though.
> I'm thinking about them. Do you know, did someone any attempts to
> implement them?

I do not remember any patches but we have touched that topic in the
past. With no conclusion AFAIR. The primary issue is that this requires
good justification and nobody seemed to have a good use case - other
than "I can imagine this could be useful". But others might disagree and
provide such use cases...

> Actually, I don't like the name of soft limits - the word "soft". It's
> not clear from the name if it's lower or upper limit.

The name might be not the best one but it makes some sense.

> It's a little bit confusing that "limit" means upper limit, and "soft
> limit" means lower limit.

It is not a lower limit. It is basically a (soft) high limit for
memory contended situations. Now it just depends on what "memory
contended situation" means and this is an internal implementation thing
(e.g. reclaim only groups which are over soft limit to reduce the
contention). Changing it from best-effort to (almost) guarantee doesn't
change the semantic of the limit for users.

> Assuming it's possible to implement strict lower limit efficiently,
> how do you call them?

This is not about efficiency but rather about an user interface. If the
current one can be used we shouldn't introduce new or we will end up in
an unusable mess.
Michal Hocko
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at