From mboxrd@z Thu Jan  1 00:00:00 1970
From: George Dunlap <george.dunlap@eu.citrix.com>
Subject: Re: [PATCH 02 of 10 v2] xen,
	libxc: introduce node maps and masks
Date: Thu, 20 Dec 2012 14:33:16 +0000
Message-ID: <50D321AC.6080400@eu.citrix.com>
References: <patchbomb.1355944036@Solace>
	<4c57c8f1e7ad20c15b8c.1355944038@Solace>
	<50D2E5EF02000078000B1B3C@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <50D2E5EF02000078000B1B3C@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>, Dan Magenheimer <dan.magenheimer@oracle.com>, Ian Campbell <Ian.Campbell@citrix.com>, Anil Madhavapeddy <anil@recoil.org>, Andrew Cooper <Andrew.Cooper3@citrix.com>, Dario Faggioli <dario.faggioli@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Matt Wilson <msw@amazon.com>, Daniel De Graaf <dgdegra@tycho.nsa.gov>, Juergen Gross <juergen.gross@ts.fujitsu.com>
List-Id: xen-devel@lists.xenproject.org

On 20/12/12 09:18, Jan Beulich wrote:
>>>> On 19.12.12 at 20:07, Dario Faggioli <dario.faggioli@citrix.com> wrote:
>> --- a/xen/include/xen/nodemask.h
>> +++ b/xen/include/xen/nodemask.h
>> @@ -298,6 +298,53 @@ static inline int __nodemask_parse(const
>>   }
>>   #endif
>>   
>> +/*
>> + * nodemask_var_t: struct nodemask for stack usage.
>> + *
>> + * See definition of cpumask_var_t in include/xen//cpumask.h.
>> + */
>> +#if MAX_NUMNODES > 2 * BITS_PER_LONG
> Is that case reasonable to expect?

2 * BITS_PER_LONG is just going to be 128, right?  It wasn't too long 
ago that I would have considered 4096 cores a pretty unreasonable 
expectation.  Is there a particular reason you think this is going to be 
more than a few years away, and a particular harm in having the code 
here to begin with?

At very least it should be replaced with something like this:

#if MAX_NUMNODES > 2 * BITS_PER_LONG
# error "MAX_NUMNODES exceeds fixed size nodemask; need to implement 
variable-length nodemasks"
#endif

  -George