From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754296AbYIRE7f (ORCPT ); Thu, 18 Sep 2008 00:59:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750832AbYIRE71 (ORCPT ); Thu, 18 Sep 2008 00:59:27 -0400 Received: from e28smtp05.in.ibm.com ([59.145.155.5]:58383 "EHLO e28esmtp05.in.ibm.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750710AbYIRE70 (ORCPT ); Thu, 18 Sep 2008 00:59:26 -0400 Message-ID: <48D1DFE0.5010208@linux.vnet.ibm.com> Date: Wed, 17 Sep 2008 21:58:08 -0700 From: Balbir Singh Reply-To: balbir@linux.vnet.ibm.com Organization: IBM User-Agent: Thunderbird 2.0.0.16 (X11/20080725) MIME-Version: 1.0 To: KAMEZAWA Hiroyuki CC: Andrew Morton , Dave Hansen , Nick Piggin , hugh@veritas.com, menage@google.com, xemul@openvz.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC][PATCH] Remove cgroup member from struct page (v3) References: <200809091500.10619.nickpiggin@yahoo.com.au> <20080909141244.721dfd39.kamezawa.hiroyu@jp.fujitsu.com> <30229398.1220963412858.kamezawa.hiroyu@jp.fujitsu.com> <20080910012048.GA32752@balbir.in.ibm.com> <1221085260.6781.69.camel@nimitz> <48C84C0A.30902@linux.vnet.ibm.com> <1221087408.6781.73.camel@nimitz> <20080911103500.d22d0ea1.kamezawa.hiroyu@jp.fujitsu.com> <48C878AD.4040404@linux.vnet.ibm.com> <20080911105638.1581db90.kamezawa.hiroyu@jp.fujitsu.com> <20080917232826.GA19256@balbir.in.ibm.com> <20080917184008.92b7fc4c.akpm@linux-foundation.org> <20080918134304.93985542.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <20080918134304.93985542.kamezawa.hiroyu@jp.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org KAMEZAWA Hiroyuki wrote: > On Wed, 17 Sep 2008 18:40:08 -0700 > Andrew Morton wrote: >>> Advantages of the patch >>> >>> 1. It removes the extra pointer in struct page >>> >>> Disadvantages >>> >>> 1. Radix tree lookup is not an O(1) operation, once the page is known >>> getting to the page_cgroup (pc) is a little more expensive now. >> Why are we doing this? I can guess, but I'd rather not have to. >> >> a) It's slower. >> >> b) It uses even more memory worst-case. >> >> c) It uses less memory best-case. >> >> someone somewhere decided that (Aa + Bb) / Cc < 1.0. What are the values >> of A, B and C and where did they come from? ;) >> > > Balbir, don't you like pre-allocate-page-cgroup-at-boot at all ? > I don't like radix-tree for objects which can spread to very vast/sparse area ;) > I tried one version, but before trying a pre-allocation version, I wanted to spread out the radix-tree and try and the results seemed quite impressive. We can still do pre-allocation, but it gets more complicated as we start supporting all memory models. I do have a design on paper, but it is much more complex than this. > BTW, I already have lazy-lru-by-pagevec protocol on my patch(hash version) and > seems to work well. I'm now testing it and will post today if I'm enough lucky. cool! Please do post what numbers you see as well. I would appreciate if you can try this version and see what sort of performance issues you see. -- Balbir From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from d28relay04.in.ibm.com (d28relay04.in.ibm.com [9.184.220.61]) by e28esmtp05.in.ibm.com (8.13.1/8.13.1) with ESMTP id m8I4xO7J001322 for ; Thu, 18 Sep 2008 10:29:24 +0530 Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8I4wh311237024 for ; Thu, 18 Sep 2008 10:29:23 +0530 Received: from d28av02.in.ibm.com (loopback [127.0.0.1]) by d28av02.in.ibm.com (8.13.1/8.13.3) with ESMTP id m8I4whLI017759 for ; Thu, 18 Sep 2008 14:58:43 +1000 Message-ID: <48D1DFE0.5010208@linux.vnet.ibm.com> Date: Wed, 17 Sep 2008 21:58:08 -0700 From: Balbir Singh Reply-To: balbir@linux.vnet.ibm.com MIME-Version: 1.0 Subject: Re: [RFC][PATCH] Remove cgroup member from struct page (v3) References: <200809091500.10619.nickpiggin@yahoo.com.au> <20080909141244.721dfd39.kamezawa.hiroyu@jp.fujitsu.com> <30229398.1220963412858.kamezawa.hiroyu@jp.fujitsu.com> <20080910012048.GA32752@balbir.in.ibm.com> <1221085260.6781.69.camel@nimitz> <48C84C0A.30902@linux.vnet.ibm.com> <1221087408.6781.73.camel@nimitz> <20080911103500.d22d0ea1.kamezawa.hiroyu@jp.fujitsu.com> <48C878AD.4040404@linux.vnet.ibm.com> <20080911105638.1581db90.kamezawa.hiroyu@jp.fujitsu.com> <20080917232826.GA19256@balbir.in.ibm.com> <20080917184008.92b7fc4c.akpm@linux-foundation.org> <20080918134304.93985542.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <20080918134304.93985542.kamezawa.hiroyu@jp.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: KAMEZAWA Hiroyuki Cc: Andrew Morton , Dave Hansen , Nick Piggin , hugh@veritas.com, menage@google.com, xemul@openvz.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org List-ID: KAMEZAWA Hiroyuki wrote: > On Wed, 17 Sep 2008 18:40:08 -0700 > Andrew Morton wrote: >>> Advantages of the patch >>> >>> 1. It removes the extra pointer in struct page >>> >>> Disadvantages >>> >>> 1. Radix tree lookup is not an O(1) operation, once the page is known >>> getting to the page_cgroup (pc) is a little more expensive now. >> Why are we doing this? I can guess, but I'd rather not have to. >> >> a) It's slower. >> >> b) It uses even more memory worst-case. >> >> c) It uses less memory best-case. >> >> someone somewhere decided that (Aa + Bb) / Cc < 1.0. What are the values >> of A, B and C and where did they come from? ;) >> > > Balbir, don't you like pre-allocate-page-cgroup-at-boot at all ? > I don't like radix-tree for objects which can spread to very vast/sparse area ;) > I tried one version, but before trying a pre-allocation version, I wanted to spread out the radix-tree and try and the results seemed quite impressive. We can still do pre-allocation, but it gets more complicated as we start supporting all memory models. I do have a design on paper, but it is much more complex than this. > BTW, I already have lazy-lru-by-pagevec protocol on my patch(hash version) and > seems to work well. I'm now testing it and will post today if I'm enough lucky. cool! Please do post what numbers you see as well. I would appreciate if you can try this version and see what sort of performance issues you see. -- Balbir -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org