![]() | |||||||||||
Messages in this thread |
> > diff -Nru a/kernel/softirq.c b/kernel/softirq.c> > --- a/kernel/softirq.c 2004-07-09 01:34:13 -07:00> > +++ b/kernel/softirq.c 2004-07-09 01:34:13 -07:00> > @@ -36,8 +36,8 @@> > */ > > > > #ifndef __ARCH_IRQ_STAT > > -irq_cpustat_t irq_stat[NR_CPUS] ____cacheline_aligned; > > -EXPORT_SYMBOL(irq_stat); > > +DEFINE_PER_CPU(irq_cpustat_t, irq_stat)> ____cacheline_maxaligned_in_smp;> > +EXPORT_PER_CPU_SYMBOL(irq_stat);> > #endif> > Is there a need for the cacheline alignment? We want to keep that per > cpu data area as packed as possible, we only want to explicitly pad if > we need to (eg other cpus are accessing that variable a lot). > > Also it looks like we will have to push the above change into the other > architectures.> > Anton> IMHO, we want to keep irq_stat aligned from performance perspectives. You can never know if the info before and after it in the per-cpu area are going to be cached (and thefore crossing cache-line boundary will cost us more). Anyhow, since that also accesses by other CPUs (not a lot...), I think it's better to keep it aligned (the utilization of per-cpu areas is so low now that it doesn't really matter). --shai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2005-03-22 14:04 [from the cache] ©2003-2008 | |||||||||||