[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48565CBA.2040309@linux.vnet.ibm.com>
Date: Mon, 16 Jun 2008 17:59:46 +0530
From: Balbir Singh <balbir@...ux.vnet.ibm.com>
To: kamezawa.hiroyu@...fujitsu.com
CC: linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>,
menage@...gle.com, xemul@...nvz.org, yamamoto@...inux.co.jp,
nishimura@....nes.nec.co.jp, lizf@...fujitsu.com
Subject: Re: [PATCH 1/6] res_counter: handle limit change
kamezawa.hiroyu@...fujitsu.com wrote:
> ----- Original Message -----
>> KAMEZAWA Hiroyuki wrote:
>>> Add a support to shrink_usage_at_limit_change feature to res_counter.
>>> memcg will use this to drop pages.
>>>
>>> Change log: xxx -> v4 (new file.)
>>> - cut out the limit-change part from hierarchy patch set.
>>> - add "retry_count" arguments to shrink_usage(). This allows that we don't
>>> have to set the default retry loop count.
>>> - res_counter_check_under_val() is added to support subsystem.
>>> - res_counter_init() is res_counter_init_ops(cnt, NULL)
>>>
>>> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
>>>
>> Does shrink_usage() really belong to res_counters? Could a task limiter, a
>> CPU/IO bandwidth controller use this callback? Resource Counters were designe
> d
>> to be generic and work across controllers. Isn't the memory controller a bett
> er
>> place for such ops.
>>
> Definitely No. I think counters which cannot be shrink should return -EBUSY
> by shrink_usage() when it cannot do it.
Wouldn't that be all counters except for the memory controller RSS counter? I
can't see anyone besides the memory controller supporting shrink_usage().
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists