Date: Thu, 23 Sep 2004 12:43:28 -0700 (PDT)
From: Christoph Lameter <christoph@lameter.com>
To: Paul Jackson <pj@sgi.com>
cc: Simon Derr <simon.derr@bull.net>, linux-kernel@vger.kernel.org
Subject: Re: [rfc][patch] 1/2 Additional cpuset features
In-Reply-To: <20040911010808.2b283c9a.pj@sgi.com>
Message-ID: <Pine.LNX.4.58.0409231238350.11694@server.home>
References: <Pine.LNX.4.58.0409101036090.2891@daphne.frec.bull.fr>
 <20040911010808.2b283c9a.pj@sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1300
Lines: 30

The cpuset relative numbering may be essential for consistent
cpu numbering f.e. in ia64's perfmon etc. This may affect multiple
subsystems of the kernel that enumerate CPUs.

Simon's 2nd patch provides a translation that we need at SGI for perfmon
support within a cpuset. Without the virtualization some
means in user space needs to exist to translate a virtual CPU number
into a physical CPU number.

On Sat, 11 Sep 2004, Paul Jackson wrote:

> Good luck with these patches, Simon, though I do not support them.
>
> For the record, I was the one most responsible for removing these two
> patches:
>
>  1) auto task migration on cpuset change, and
>  2) cpuset relative CPU/Memory numbering.
>
> I continue to think that these can be done just as well in user space.
> A bit better in user space actually, as the locking for (1) is easier
> from user space, and the opportunity for more flexible adaption to
> different renumbering needs that (2) attempts is easier from user space.
>
> But if others find these worth persuing in kernel space, so be it.
-
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/