Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030506AbWHIGAP (ORCPT ); Wed, 9 Aug 2006 02:00:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030508AbWHIGAP (ORCPT ); Wed, 9 Aug 2006 02:00:15 -0400 Received: from qb-out-0506.google.com ([72.14.204.237]:12730 "EHLO qb-out-0506.google.com") by vger.kernel.org with ESMTP id S1030506AbWHIGAM (ORCPT ); Wed, 9 Aug 2006 02:00:12 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=g3JVzZ1wmxzSBF4l9nx8ZQoq2UwujiDRQIvGQgf60UVS6pGBOZ4yef0U+6tTsgeCKHTr0qpGUJI8kvJsbqYJXeYJEd4MK5KqJiexyeb7qsgY8s25kqHtLWL//OX6s0MuEzm5lsnYSm5yMbc3/ZQmOmE8PQczLVMOxBjMHEAbkHQ= Message-ID: Date: Wed, 9 Aug 2006 15:00:01 +0900 From: "Magnus Damm" To: "Andi Kleen" Subject: Re: memory resource accounting (was Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller) Cc: "Nick Piggin" , rohitseth@google.com, "Dave Hansen" , "Kirill Korotaev" , vatsa@in.ibm.com, "Alan Cox" , "Andrew Morton" , mingo@elte.hu, sam@vilain.net, linux-kernel@vger.kernel.org, dev@openvz.org, efault@gmx.de, balbir@in.ibm.com, sekharan@us.ibm.com, nagar@watson.ibm.com, pj@sgi.com, "Andrey Savochkin" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060804050753.GD27194@in.ibm.com> <44D6EAFA.8080607@sw.ru> <44D74F77.7080000@mbligh.org> <44D76B43.5080507@sw.ru> <1154975486.31962.40.camel@galaxy.corp.google.com> <1154976236.19249.9.camel@localhost.localdomain> <1154977257.31962.57.camel@galaxy.corp.google.com> <44D798B1.8010604@mbligh.org> <44D89D7D.8040006@yahoo.com.au> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1881 Lines: 38 On 09 Aug 2006 06:33:54 +0200, Andi Kleen wrote: > Nick Piggin writes: > > > > - each struct page has a backpointer to its billed container. At the mm > > summit Linus said he didn't want back pointers, but I clarified with him > > and he isn't against them if they are easily configured out when not using > > memory controllers. > > This would need to be done at runtime though, otherwise it's useless > for distributions and other people who want single kernel binary images. > > Probably would need a second parallel table, but for that you would > need to know at boot already if you plan to use them or not. Ugly. I've been thinking a bit about replacing the mapping and index members in struct page with a single pointer that point into a cluster data type. The cluster data type is aligned to a power of two and contains a header that is shared between all pages within the cluster. The header contains a base index and mapping. The rest of the cluster is an array of pfn:s that point back to the actual page. The cluster can be seen as a leaf node in the inode radix tree. Contiguous pages in inode space are kept together in the cluster - not physically contiguous pages. The cluster pointer in struct page is used together with alignment to determine the address of the cluster header and the real index (alignment + base index). Anyway, what has all this to do with memory resource management? It should be possible to add a per-cluster container pointer in the header. This way the per-page overhead is fairly small - all depending on the cluster size of course. / magnus - 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/