Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932065AbWITRQG (ORCPT ); Wed, 20 Sep 2006 13:16:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932067AbWITRQG (ORCPT ); Wed, 20 Sep 2006 13:16:06 -0400 Received: from omx1-ext.sgi.com ([192.48.179.11]:54756 "EHLO omx1.americas.sgi.com") by vger.kernel.org with ESMTP id S932066AbWITRQD (ORCPT ); Wed, 20 Sep 2006 13:16:03 -0400 Date: Wed, 20 Sep 2006 10:15:52 -0700 (PDT) From: Christoph Lameter To: Alan Cox cc: Rohit Seth , CKRM-Tech , devel@openvz.org, pj@sgi.com, npiggin@suse.de, linux-kernel Subject: Re: [patch00/05]: Containers(V2)- Introduction In-Reply-To: <1158773699.7705.19.camel@localhost.localdomain> Message-ID: References: <1158718568.29000.44.camel@galaxy.corp.google.com> <1158773699.7705.19.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1535 Lines: 30 On Wed, 20 Sep 2006, Alan Cox wrote: > Ar Mer, 2006-09-20 am 09:25 -0700, ysgrifennodd Christoph Lameter: > > We already have such a functionality in the kernel its called a cpuset. A > > container could be created simply by creating a fake node that then > > allows constraining applications to this node. We already track the > > types of pages per node. The statistics you want are already existing. > > See /proc/zoneinfo and /sys/devices/system/node/node*/*. > > CPUsets don't appear to scale to large numbers of containers (say 5000, > with 200-500 doing stuff at a time). They also don't appear to do any > tracking of kernel side resource objects, which is critical to > containment. Indeed for some of us the CPU management and user memory > management angle is mostly uninteresting. The scalability issues can certainly be managed. See the discussions on linux-mm. Kernel side resource objects? slab pages? Those are tracked. > I'm also not clear how you handle shared pages correctly under the fake > node system, can you perhaps explain that further how this works for say > a single apache/php/glibc shared page set across 5000 containers each a > web site. Cpusets can share nodes. I am not sure what the problem would be? Paul may be able to give you more details. - 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/