[lkml]   [2011]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC 0/3] Implementation of cgroup isolation
    On Tue 29-03-11 21:15:59, Zhu Yanhai wrote:
    > Michal,


    > Maybe what we need here is some kind of trade-off?
    > Let's say a new configuable parameter reserve_limit, for the cgroups
    > which want to
    > have some guarantee in the memory resource, we have:
    > limit_in_bytes > soft_limit > reserve_limit
    > MEM[limit_in_bytes..soft_limit] are the bytes that I'm willing to contribute
    > to the others if they are short of memory.
    > MEM[soft_limit..reserve_limit] are the bytes that I can afford if the others
    > are still eager for memory after I gave them MEM[limit_in_bytes..soft_limit].
    > MEM[reserve_limit..0] are the bytes which is a must for me to guarantee QoS.
    > Nobody is allowed to steal them.
    > And reserve_limit is 0 by default for the cgroups who don't care about Qos.
    > Then the reclaim path also needs some changes, i.e, balance_pgdat():
    > 1) call mem_cgroup_soft_limit_reclaim(), if nr_reclaimed is meet, goto finish.
    > 2) shrink the global LRU list, and skip the pages which belong to the cgroup
    > who have set a reserve_limit. if nr_reclaimed is meet, goto finish.

    Isn't this an overhead that would slow the whole thing down. Consider
    that you would need to lookup page_cgroup for every page and touch
    mem_cgroup to get the limit.
    The point of the isolation is to not touch the global reclaim path at

    > 3) shrink the cgroups who have set a reserve_limit, and leave them with only
    > the reserve_limit bytes they need. if nr_reclaimed is meet, goto finish.
    > 4) OOM
    > Does it make sense?

    It sounds like a good thing - in that regard it is more generic than
    a simple flag - but I am afraid that the implementation wouldn't be
    that easy to preserve the performance and keep the balance between
    groups. But maybe it can be done without too much cost.

    Michal Hocko
    SUSE Labs
    SUSE LINUX s.r.o.
    Lihovarska 1060/12
    190 00 Praha 9
    Czech Republic

     \ /
      Last update: 2011-03-29 15:45    [W:0.022 / U:55.004 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site