lkml.org 
[lkml]   [2010]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] [PATCH 0/2] memcg: per cgroup dirty limit
    On Mon, Feb 22, 2010 at 01:29:34PM -0500, Vivek Goyal wrote:
    > > I would't like to add many different interfaces to do the same thing.
    > > I'd prefer to choose just one interface and always use it. We just have
    > > to define which is the best one. IMHO dirty_bytes is more generic. If
    > > we want to define the limit as a % we can always do that in userspace.
    > >
    >
    > dirty_ratio is easy to configure. One system wide default value works for
    > all the newly created cgroups. For dirty_bytes, you shall have to
    > configure each and individual cgroup with a specific value depneding on
    > what is the upper limit of memory for that cgroup.

    OK.

    >
    > Secondly, memory cgroup kind of partitions global memory resource per
    > cgroup. So if as long as we have global dirty ratio knobs, it makes sense
    > to have per cgroup dirty ratio knob also.
    >
    > But I guess we can introduce that later and use gloabl dirty ratio for
    > all the memory cgroups (instead of each cgroup having a separate dirty
    > ratio). The only thing is that we need to enforce this dirty ratio on the
    > cgroup and if I am reading the code correctly, your modifications of
    > calculating available_memory() per cgroup should take care of that.

    At the moment (with dirty_bytes) if the cgroup has dirty_bytes == 0, it
    simply uses the system wide available_memory(), ignoring the memory
    upper limit for that cgroup and fallbacks to the current behaviour.

    With dirty_ratio, should we change the code to *always* apply this
    percentage to the cgroup memory upper limit, and automatically set it
    equal to the global dirty_ratio by default when the cgroup is created?
    mmmh... I vote yes.

    -Andrea


    \
     
     \ /
      Last update: 2010-02-23 10:59    [W:3.497 / U:0.176 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site