From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 1/2] IRQ: allocate CPU masks dynamically Date: Thu, 3 Nov 2011 16:02:10 +0000 Message-ID: <4EB2BB02.5030107@citrix.com> References: <4EB2B2B5020000780005EBDD@nat28.tlf.novell.com> <4EB2A9F5.1060800@citrix.com> <4EB2BE9E020000780005EC7F@nat28.tlf.novell.com> <4EB2B69A.5030007@citrix.com> <4EB2C688020000780005ECDF@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4EB2C688020000780005ECDF@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: "xen-devel@lists.xensource.com" , "Keir (Xen.org)" List-Id: xen-devel@lists.xenproject.org On 03/11/11 15:51, Jan Beulich wrote: >>>> On 03.11.11 at 16:43, Andrew Cooper wrote: >> On 03/11/11 15:17, Jan Beulich wrote: >>>>>> On 03.11.11 at 15:49, Andrew Cooper wrote: >>>> On 03/11/11 14:26, Jan Beulich wrote: >>>>> IRQ: allocate CPU masks dynamically >>>>> >>>>> This includes delaying the initialization of dynamically created IRQs >>>>> until their actual first use and some further elimination of uses of >>>>> struct irq_cfg. >>>>> >>>>> Signed-off-by: Jan Beulich >>>> Acked-by: Andrew Cooper >>>> >>>> One query which may or may not affect the patch. Would we get better >>>> caching characteristics if all cpumasks were allocated in consecutive >>>> memory, rather than having 3 individual allocs in arch_init_one_irq_desc ? >>> That was what the first version of the patch did, rejected by Keir >>> (and not liked too much by me either). >>> >>> Jan >> My understanding of the objection was hiding the variables themselves as >> an array in the code. >> >> An alternative approach such as alloc'ing 3*sizeof(cpu mask) (cache >> aligned) and assigning the relevant pointers to the current >> cpumask_var_t's would be a suitable approach which causes the cpumasks >> to be in contiguous memory, but not changing how they are referenced in >> the code. > That would mean just open-coding what the former patch did by > abstraction. In my opinion that is even worse - either we want a > generally usable mechanism to do this, or we don't do it at all. > > Jan That is an interesting point, but I dont think it is worse. There are very few cases where we want to be doing this, so open coding is not too bad. With a comment explaining why, I would have thought it would be fine. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com