Messages in this thread | | | Date | Tue, 17 Feb 2009 14:10:39 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [RFC][PATCH 0/4] Memory controller soft limit patches (v2) |
| |
On Tue, 17 Feb 2009 10:11:10 +0530 Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-02-17 13:03:52]: > > > On Tue, 17 Feb 2009 08:35:26 +0530 > > Balbir Singh <balbir@linux.vnet.ibm.com> wrote: > > I don't want to add any new big burden to kernel hackers of memory management, > > they work hard to improve memory reclaim. This patch will change the behavior. > > > > I don't think I agree, this approach suggests that before doing global > reclaim, there are several groups that are using more than their > share of memory, so it makes sense to reclaim from them first. >
> > > BTW, in typical bad case, several threads on cpus goes into memory recalim at once and > > all thread will visit this memcg's soft-limit tree at once and soft-limit will > > not work as desired anyway. > > You can't avoid this problem at alloc_page() hot-path. > > Even if all threads go into soft-reclaim at once, the tree will become > empty after a point and we will just return saying there are no more > memcg's to reclaim from (we remove the memcg from the tree when > reclaiming), then those threads will go into regular reclaim if there > is still memory pressure.
Yes. the largest-excess group will be removed. So, it seems that it doesn't work as designed. rbtree is considered as just a hint ? If so, rbtree seems to be overkill.
just a question: Assume memcg under hierarchy. ../group_A/ usage=1G, soft_limit=900M hierarchy=1 01/ usage=200M, soft_limit=100M 02/ usage=300M, soft_limit=200M 03/ usage=500M, soft_limit=300M <==== 200M over. 004/ usage=200M, soft_limit=100M 005/ usage=300M, soft_limit=200M
At memory shortage, group 03's memory will be reclaimed - reclaim memory from 03, 03/004, 03/005
When 100M of group 03' memory is reclaimed, group_A 's memory is reclaimd at the same time, implicitly. Doesn't this break your rb-tree ?
I recommend you that soft-limit can be only applied to the node which is top of hierarchy. > > > > > > 3. After this patch, res_counter is no longer for general purpose res_counter... > > > > It seems to have too many unnecessary accessories for general purpose. > > > > > > Why not? Soft limits are a feature of any controller. The return of > > > highest ancestor might be the only policy we impose right now. But as > > > new controllers start using res_counter, we can clearly add a policy > > > callback. > > > > > I think you forget that memroy cgroups is an only controller in which the kernel > > can reduce the usage of resource without any harmful to users. > > soft-limit is nonsense for general resources, I think. > > > > Really? Even for CPUs? soft-limit is a form of shares (please don't > confuse with cpu.shares). Soft limits is used as a way of implementing > work conserving controllers. >
I don't think cpu needs this. It works under share and no hardlimit.
THanks, -Kame
| |