lkml.org 
[lkml]   [2008]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/6] res_counter: handle limit change
    kamezawa.hiroyu@jp.fujitsu.com wrote:
    > ----- Original Message -----
    >
    >>> I think when I did all in memcg, someone will comment that "why do that
    >>> all in memcg ? please implement generic one to avoid code duplication"
    >> Hm... But we're choosing between
    >>
    >> sys_write->xxx_cgroup_write->res_counter_set_limit->xxx_cgroup_call
    >>
    >> and
    >>
    >> sys_write->xxx_cgroup_write->res_counter_set_limit
    >> ->xxx_cgroup_call
    >>
    >> With the sizeof(void *)-bytes difference in res_counter, nNo?
    >>
    > I can't catch what you mean. What is res_counter_set_limit here ?

    It's res_counter_resize_limit from your patch, sorry for the confusion.

    > (my patche's ?) and what is sizeof(void *)-bytes ?

    I meant, that we have to add 4 bytes (8 on 64-bit arches) on the
    struct res_counter to store the pointer on the res_counter_ops.

    > Is it so strange to add following algorithm in res_counter?
    > ==
    > set_limit -> fail -> shrink -> set limit -> fail ->shrink
    > -> success -> return 0
    > ==
    > I think this is enough generic.

    It is, but my point is - we're calling the set_limit (this is a
    res_counter_resize_limit from your patch, sorry for the confusion again)
    routine right from the cgroup's write callback and thus can call
    the desired "ops->shrink_usage" directly, w/o additional level of
    indirection.

    > Thanks,
    > -Kame
    >
    >
    >
    >



    \
     
     \ /
      Last update: 2008-06-16 10:31    [W:0.024 / U:29.640 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site