Re: [patch] Pad irq_desc to internode cacheline size

[Andrew Morton <akpm@linux-foundation.org>]

On Mon, 9 Apr 2007 12:56:27 -0700
Ravikiran G Thirumalai <kiran@scalex86.org> wrote:

> We noticed a drop in n/w performance due to the irq_desc being cacheline
> aligned rather than internode aligned.  We see 50% of expected performance
> when two e1000 nics local to two different nodes have consecutive irq
> descriptors allocated, due to false sharing.
> 
> Note that this patch does away with cacheline padding for the UP case, as it
> does not seem useful for UP configurations.
> 
> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
> Signed-off-by: Shai Fultheim <shai@scalex86.org>
> 
> Index: linux-2.6.21-rc5/include/linux/irq.h
> ===================================================================
> --- linux-2.6.21-rc5.orig/include/linux/irq.h	2007-04-09 10:16:23.560848473 -0700
> +++ linux-2.6.21-rc5/include/linux/irq.h	2007-04-09 10:16:45.401177929 -0700
> @@ -175,7 +175,7 @@ struct irq_desc {
>  	struct proc_dir_entry	*dir;
>  #endif
>  	const char		*name;
> -} ____cacheline_aligned;
> +} ____cacheline_internodealigned_in_smp;
>  
>  extern struct irq_desc irq_desc[NR_IRQS];

This will consume nearly 4k per irq won't it?  What is the upper bound
here, across all configs and all hardware?

Is VSMP the only arch which has ____cacheline_internodealigned_in_smp
larger than ____cacheline_aligned_in_smp?