linux-kernel - Re: BC: resource beancounters (v2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1156783721.8317.6.camel@galaxy.corp.google.com>
Date:	Mon, 28 Aug 2006 09:48:41 -0700
From:	Rohit Seth <rohitseth@...gle.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Andrey Savochkin <saw@...ru>, Andrew Morton <akpm@...l.org>,
	Kirill Korotaev <dev@...ru>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Pavel Emelianov <xemul@...nvz.org>, devel@...nvz.org,
	Rik van Riel <riel@...hat.com>, Andi Kleen <ak@...e.de>,
	Greg KH <greg@...ah.com>, Oleg Nesterov <oleg@...sign.ru>,
	Matt Helsley <matthltc@...ibm.com>,
	Chandra Seetharaman <sekharan@...ibm.com>
Subject: Re: BC: resource beancounters (v2)

On Sat, 2006-08-26 at 17:37 +0100, Alan Cox wrote:
> Ar Gwe, 2006-08-25 am 19:15 -0700, ysgrifennodd Rohit Seth:
> > Yes, sharing of pages across different containers/managers will be a
> > problem.  Why not just disallow that scenario (that is what fake nodes
> > proposal would also end up doing).
> 
> Because it destroys the entire point of using containers instead of
> something like Xen - which is sharing. Also at the point I am using
> beancounters per user I don't want glibc per use, libX11 per use glib
> per use gtk per user etc..
> 
> 

I'm not saying per use glibc etc.  That will indeed be useless and bring
it to virtualization world.  Just like fake node, one should be allowed
to use pages that are already in  (for example) page cache- so that you
don't end up duplicating all shared stuff.  But as far as charging is
concerned, charge it to container who either got the page in page cache
OR if FS based semantics exist then charge it to the container where the
file belongs.  What I was suggesting is to not charge a page to
different counters.

-rohit

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/