Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751116AbWHVBtV (ORCPT ); Mon, 21 Aug 2006 21:49:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751119AbWHVBtV (ORCPT ); Mon, 21 Aug 2006 21:49:21 -0400 Received: from smtp-out.google.com ([216.239.45.12]:3938 "EHLO smtp-out.google.com") by vger.kernel.org with ESMTP id S1751116AbWHVBtT (ORCPT ); Mon, 21 Aug 2006 21:49:19 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:subject:from:reply-to:to:cc:in-reply-to:references: content-type:organization:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=q5rNuhLe7KLV2s5dygjXcWKpuVTarL/WRO+u8lIUWCjILOJYpLd8DpZqEvhmHD3C/ Oy+8PQe9GP551E+Q/ZhNg== Subject: Re: [ckrm-tech] [RFC][PATCH 5/7] UBC: kernel memory accounting (core) From: Rohit Seth Reply-To: rohitseth@google.com To: Kirill Korotaev Cc: Rik van Riel , ckrm-tech@lists.sourceforge.net, Dave Hansen , Linux Kernel Mailing List , Andi Kleen , Christoph Hellwig , Andrey Savochkin , devel@openvz.org, hugh@veritas.com, Ingo Molnar , Alan Cox , Pavel Emelianov In-Reply-To: <44E99904.80205@sw.ru> References: <44E33893.6020700@sw.ru> <44E33C8A.6030705@sw.ru> <1155754029.9274.21.camel@localhost.localdomain> <1155755729.22595.101.camel@galaxy.corp.google.com> <1155758369.9274.26.camel@localhost.localdomain> <1155774274.15195.3.camel@localhost.localdomain> <1155824788.9274.32.camel@localhost.localdomain> <1155835003.14617.45.camel@galaxy.corp.google.com> <1155835401.9274.64.camel@localhost.localdomain> <1155836198.14617.61.camel@galaxy.corp.google.com> <44E58059.6020605@sw.ru> <1155922680.23242.7.camel@galaxy.corp.google.com> <44E99904.80205@sw.ru> Content-Type: text/plain Organization: Google Inc Date: Mon, 21 Aug 2006 18:48:00 -0700 Message-Id: <1156211280.11127.41.camel@galaxy.corp.google.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1365 Lines: 38 On Mon, 2006-08-21 at 15:29 +0400, Kirill Korotaev wrote: > >>in case of anon_vma, page->mapping can be the same > >>for 2 pages beloning to different containers. > >> > > > > > > In your experience, have you seen processes belonging to different > > containers sharing the same anon_vma? On a more general note, could you > > please point me to a place that has the list of requirements for which > > we are designing this solution. > > > > > >>>>nor is it ambiguous in any way. It is very strict, > >>>>and very straightforward. > >>> > >>>What additional ambiguity you have when inode or task structures have > >>>the required information. > >> > >>inodes can belong to multiple containers and so do the pages. > >> > > > > > > I'm still thinking that inodes should belong to one container (or may be > > have it configurable based on some flag). > this is not true for OpenVZ nor Linux-VServer. Well, it is still useful. Just like an anonymous page get charged to container where the object (task) belong to, file page seems appropriate to belong to container where the object (inode) belongs to. -rohit - 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/