From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 2/2] kvm: use cpumask_var_t for cpus_hardware_enabled Date: Mon, 08 Dec 2008 11:46:44 +0200 Message-ID: <493CED04.6020209@redhat.com> References: <200812072125.45757.rusty@rustcorp.com.au> <493BF206.4070007@redhat.com> <200812081635.35166.rusty@rustcorp.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-devel , linux-kernel@vger.kernel.org, Mike Travis To: Rusty Russell Return-path: Received: from mx2.redhat.com ([66.187.237.31]:39115 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751181AbYLHJqh (ORCPT ); Mon, 8 Dec 2008 04:46:37 -0500 In-Reply-To: <200812081635.35166.rusty@rustcorp.com.au> Sender: kvm-owner@vger.kernel.org List-ID: Rusty Russell wrote: >> This isn't on stack, so it isn't buying us anything. >> > > It's the CONFIG_NR_CPUS=4096 but nr_cpu_ids=4 case which we win using > dynamic allocation. Gotta love distribution kernels. > > What does it buy? 4096/8 = 512 bytes statically allocated? I understand passing things as pointers, but allocating everything dynamically is unCish. >> Is the plan to drop cpumask_t? >> > > Yes. And undefine 'struct cpumask' if CONFIG_CPUMASK_OFFSTACK. That > will stop assignment and on-stack declarations for all but the most > determined. > > >> If so, we're penalizing non-stack users >> by forcing them to go through another pointer (and cacheline). >> > > Not quite. If !CONFIG_CPUMASK_OFFSTACK, cpumask_var_t == cpumask_t[1]. > Blame Linus :) > Hm, is there a C trick which will error out when allocating something on the stack, but work when allocating statically? I can think of something to do the reverse, but that doesn't help. Maybe a weak or visibility attribute? These don't make sense on function locals. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.