This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [Patch] use full-size cpumask for vcpu-pin

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [Patch] use full-size cpumask for vcpu-pin
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Fri, 13 Aug 2010 14:30:35 +0100
Cc: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 13 Aug 2010 06:31:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C88B065A.1DB59%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acs66P6ihsUYSx3hTHqLrb2bGAI6HQAAKSSBAAA3bqQAAB++rgAALXP1
Thread-topic: [Xen-devel] [Patch] use full-size cpumask for vcpu-pin
User-agent: Microsoft-Entourage/
On 13/08/2010 14:25, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

> On 13/08/2010 14:21, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
>>> Since Xen discards any CPUs which are not online at the time of the
>>> setvcpuaffinity hypercall, expressing "all CPUs present and future" is a bit
>>> pointless.
>> Hm, no, I'm talking rubbish. Argh. Okay, his patch is fine then. :-D
>> You can check it in to xen-unstable-tools.hg.
> One suggestion: that we rename the syctl.physinfo field 'max_phys_cpus' to
> 'max_possible_cpus'. The 'phys' is kind of redundant since this is the
> physinfo sysctl, and 'possible' provides a better hint that this fields
> indicates maximum possible supported CPUs now and forever on this boot of
> the system.

Even better, let's not introduce a new field at all, and let's always set
sysctl.phys_info.max_cpu_id to NR_CPUS-1. Then I don't think any tools
changes are needed.

Yeah, that's what we should do. I will make a patch for that.

 -- Keir

>  -- Keir

Xen-devel mailing list