Re: [PATCH] memcg: implement low limits

From: Roman Gushchin
Date: Thu Feb 28 2013 - 06:13:27 EST

27.02.2013, 20:14, "Michal Hocko" <mhocko@xxxxxxx>:
> On Wed 27-02-13 14:39:36, Roman Gushchin wrote:
>>  27.02.2013, 13:41, "Michal Hocko" <mhocko@xxxxxxx>:
>>>  Let me restate what I have already mentioned in the private
>>>  communication.
>>>  We already have soft limit which can be implemented to achieve the
>>>  same/similar functionality and in fact this is a long term objective (at
>>>  least for me). I hope I will be able to post my code soon. The last post
>>>  by Ying Hand (cc-ing her) was here:
>>>  To be honest I do not like introduction of a new limit because we have
>>>  two already and the situation would get over complicated.
>>  I think, there are three different tasks:
>>  1) keeping cgroups below theirs hard limit to avoid direct reclaim
>>  (for performance reasons),
> Could you clarify what you mean by this, please? There is no background
> reclaim for memcgs currently and I am a bit skeptical whether it is
> useful. If it would be useful then it should be in par with the global
> reclaim (so something like min_free_kbytes would be more appropriate).

I mean, that it's a good idea to keep memory usage of any cgroup a little bit
under it's hard limit to avoid direct reclaim. There is no good mechanism yet,
but it can be developed later.

>>  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 have an idea how to implement them (and also implementing (fast) strict lower limits limits).
I'll try to post my version soon.

>>  3) granting some amount of memory to a selected cgroup (and protecting
>>  it from reclaim without significant reasons)
> and soft limit sounds like a good fit with this description.
>>  IMHO, combining them all in one limit will simplify a kernel code,
>>  but will also make a user's (or administrator's) life much more
>>  complicated.
> I do not think all 3 tasks you have described can be covered by a single
> limit of course. We have hard limit to cap the usage, we have a soft
> limit to allow over-committing the machine. Task 2 would require a new
> knob but it shouldn't be covered by any limit or depend on the group
> usage. And task 1 sounds like a background reclaim and then it should be
> consistent with the global knob.
>>  Introducing low limits can make the situation simpler.
> How exactly? I can see how it would address task 3 but yet again, soft
> limit can be turned into this behavior as well without changing its
> semantic (that limit would be still considered if we are able to handle
> memory pressure from the above - either global pressure or parent
> hitting the limit).

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. It's a little bit confusing that "limit"
means upper limit, and "soft limit" means lower limit.

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

Thank you!

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