Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932253AbWIRLcj (ORCPT ); Mon, 18 Sep 2006 07:32:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932273AbWIRLcj (ORCPT ); Mon, 18 Sep 2006 07:32:39 -0400 Received: from mailhub.sw.ru ([195.214.233.200]:1846 "EHLO relay.sw.ru") by vger.kernel.org with ESMTP id S932253AbWIRLci (ORCPT ); Mon, 18 Sep 2006 07:32:38 -0400 Message-ID: <450E83D0.6080205@openvz.org> Date: Mon, 18 Sep 2006 15:32:32 +0400 From: Pavel Emelianov User-Agent: Thunderbird 1.5 (X11/20060317) MIME-Version: 1.0 To: balbir@in.ibm.com CC: sekharan@us.ibm.com, Srivatsa , Rik van Riel , Alan Cox , CKRM-Tech , Dave Hansen , Andi Kleen , Linux Kernel Mailing List , Christoph Hellwig , Andrey Savochkin , Matt Helsley , Hugh Dickins , Alexey Dobriyan , Kirill Korotaev , Oleg Nesterov , devel@openvz.org Subject: Re: [ckrm-tech] [PATCH] BC: resource beancounters (v4) (added user memory) References: <44FD918A.7050501@sw.ru> <44FDAB81.5050608@in.ibm.com> <44FEC7E4.7030708@sw.ru> <44FF1EE4.3060005@in.ibm.com> <1157580371.31893.36.camel@linuxchandra> <45011CAC.2040502@openvz.org> <1157730221.26324.52.camel@localhost.localdomain> <4501B5F0.9050802@in.ibm.com> <450508BB.7020609@openvz.org> <4505161E.1040401@in.ibm.com> <45051AC7.2000607@openvz.org> <1158000590.6029.33.camel@linuxchandra> <45069072.4010007@openvz.org> <1158105488.4800.23.camel@linuxchandra> <4507BC11.6080203@openvz.org> <1158186664.18927.17.camel@linuxchandra> <45090A6E.1040206@openvz.org> <1158277364.6357.33.camel@linuxchandra> <450A5325.6090803@openvz.org> <450A6A7A.8010102@sw.ru> <450A8B61.7040905@openvz.org> <450E5813.2040804@in.ibm.com> <450E5F2E.2070809@openvz.org> <450E8113.30602@in.ibm.com> In-Reply-To: <450E8113.30602@in.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3133 Lines: 86 Balbir Singh wrote: > Pavel Emelianov wrote: >> Balbir Singh wrote: >> >> [snip] >> >>> This approach has the following disadvantages >>> 1. Lets consider initialization - When we create 'n' groups >>> initially, we need >>> to spend O(n^2) time to assign guarantees. >> >> 1. Not guarantees - limits. If you do not need guarantees - assign >> overcommited limits. Most of OpenVZ users do so and nobody claims. >> 2. If you start n groups at once then limits are calculated in O(n) >> time, not O(n^2). > > Yes.. if you start them at once, but if they are incrementally > added and started it is O(n^2) See my comment below. > >> >>> 2. Every time a limit or a guarantee changes, we need to recalculate >>> guarantees >>> and ensure that the change will not break any guarantees >> >> The same. >> >>> 3. The same thing as stated above, when a resource group is created >>> or deleted >>> >>> This can lead to some instability; a change in one group propagates to >>> all other groups. >> >> Let me cite a part of your answer on my letter from 11.09.2006: >> "... >> xemul> I have a node with 1Gb of ram and 10 containers with 100Mb >> xemul> guarantee each. I want to start one more. >> xemul> What shall I do not to break guarantees? >> >> Don't start the new container or change the guarantees of the >> existing ones to accommodate this one ... It would be perfectly >> ok to have a container that does not care about guarantees to >> set their guarantee to 0 and set their limit to the desired value >> ..." >> >> The same for the limiting - either do not start new container, or >> recalculate limits to meet new requirements. You may not take care of >> guarantees as weel and create an overcommited configuration. As I do not see any reply on this I consider "O(n^2) disadvantage" to be irrelevant. >> >> And one more thing. We've asked it many times and I ask it again - >> please, show us the other way for providing guarantee rather than >> limiting or reserving. > > There are some other options, I am sure Chandra will probably have > more. > > 1. Reclaim resources from other containers. This can be done well for > user-pages, if we ensure that each container does not mlock more > than its guaranteed share of memory. We've already agreed to consider unreclaimable resources only. If we provide reclaimable memory *only* then we can provide any guarantee with a single page available for user-space. Unreclaimable resource is the most interesting one. > 2. Provide best effort guarantees for non-reclaimable memory That's the question - how? > 3. oom-kill a container or a task within a resource group that has > exceeded its guarantee and some other container is unable to meet its > guarantee Oom-killer must start only when there are no other ways to find memory. This must be a "last argument", not the regular solution. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/