Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750768AbWIOIvA (ORCPT ); Fri, 15 Sep 2006 04:51:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750772AbWIOIvA (ORCPT ); Fri, 15 Sep 2006 04:51:00 -0400 Received: from mailhub.sw.ru ([195.214.233.200]:43150 "EHLO relay.sw.ru") by vger.kernel.org with ESMTP id S1750768AbWIOIu7 (ORCPT ); Fri, 15 Sep 2006 04:50:59 -0400 Message-ID: <450A6A7A.8010102@sw.ru> Date: Fri, 15 Sep 2006 12:55:22 +0400 From: Kirill Korotaev User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060417 X-Accept-Language: en-us, en, ru MIME-Version: 1.0 To: Pavel Emelianov CC: sekharan@us.ibm.com, balbir@in.ibm.com, Srivatsa , Rik van Riel , CKRM-Tech , Dave Hansen , Linux Kernel Mailing List , Andi Kleen , Christoph Hellwig , Andrey Savochkin , devel@openvz.org, Matt Helsley , Hugh Dickins , Alexey Dobriyan , Oleg Nesterov , Alan Cox 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> In-Reply-To: <450A5325.6090803@openvz.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1831 Lines: 47 Chandra, >>>>What if I have 40 containers each with 2% guarantee ? what do we do >>>>then ? and many other different combinations (what I gave was not the >>>>_only_ scenario). >>>> >>>> >>> >>>Then you need to solve a set of 40 equations. This sounds weird, but >>>don't afraid - sets like these are solved lightly. >>> >> >>extrapolate that to a varying # of permutations and real time changes in >>the system workload. Won't it be complex ? >> > > I have a C program that computes limits to obtain desired guarantees > in a single 'for (i = 0; i < n; n++)' loop for any given set of guarantees. > With all error handling, beautifull output, nice formatting etc it weights > only 60 lines. > >>Wouldn't it be a lot simpler if we have the guarantee support instead ? the calculation above doesn't seem hard :) >>Why you do not like guarantee ? :) > I do not 'do not like guarantee'. I'm just sure that there are two ways > for providing guarantee (for unreclaimable resorces): > 1. reserving resource for group in advance > 2. limit resource for others > Reserving is worse as it is essentially limiting (you cut off 100Mb from > 1Gb RAM thus limiting the other groups by 900Mb RAM), but this limiting > is too strict - you _have_ to reserve less than RAM size. Limiting in > run-time is more flexible (you may create an overcommited BC if you > want to) and leads to the same result - guarantee. I think this deserves putting on Wiki. It is very good clear point. Chanrda, do you propose some 3rd way (we are unaware of) of implementing guarantees? Thanks, Kirill - 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/