[lkml]   [2008]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Re: [PATCH 1/6] res_counter: handle limit change
----- Original Message -----
>> Okay, maye all you want is "don't increase the size of res_counter"
>Actually no, what I want is not to put indirections level when
>not required.
"not required" ? I think you miss the point that this patch implements some
feedback algorithm in res_counter. If res_counter doesn't support it,
Okay, I'll do in memcg. But please see this request from Paul in the prev vers
And what benefits we can get by implementing feedback per subcgroups ?

>But keeping res_counter as small as possible is also my wish. :)
>>>> 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.
>> Hmm, to do that, I'd like to remove strategy function from res_counter.
>Oops... I'm looking at 2.6.26-rc5-mm1's res_counter and don't see such.
>I tried to follow the changes in res_counter, but it looks like I've
>already missed something.
>What do you mean by "strategy function from res_counter"?
Please ignore. my confusion.
"don't call res_counter_write() at set limit" is ok.


 \ /
  Last update: 2008-06-16 11:05    [W:0.092 / U:1.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site