lkml.org 
[lkml]   [2004]   [Jul]   [12]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSun, 11 Jul 2004 22:11:26 -0700
FromAndrew Morton <>
SubjectRe: [PATCH] PER_CPU [4/4] - PER_CPU-irq_stat
"Shai Fultheim" <shai@scalex86.org> wrote:
>
> > > 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).
> 

That seems a bit debatable.

But anyway, as Anton points out, the patch breaks !x86 architectures.
-
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