Re: [Xen-devel] [patch] bitops on irq_cpustat_t->__softirq_pending

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

On Mar 30, 2006, at 7:25 PM, Tian, Kevin wrote:

> > From: Hollis Blanchard
> > Sent: 2006年3月31日 0:45
> > Instead, this patch changes asm-x86/hardirq.h to use a long where PPC
> > needs
> > it. This doesn't change the size of the structure for x86. There are 
> > other
> > ways we could and should do this code-sharing, but this one is the 
> > least
> > impact (and this is an area where IA64's divergence is potentially
> > problematic).
> Xen/IA64 has percpu hardware pages support and so softirq pending
> indicator is put together with other more percpu stuffs placed on the
> percpu pages. That can accelerate percpu access a lot.
Makes sense. In fact I would say any array with NR_CPUS elements should 
probably be in a per-cpu data area to avoid "__cacheline_aligned" 
padding.
However, we don't have a standard infrastructure for that in Xen right 
now, and that means that IA64's hardirq.h, part of the weird 
suck-in-headers-from-Linux thing, is radically different from x86 (and 
thus PPC). And *that* means it's quite difficult to make any changes to 
hardirq.h without fear of breaking the IA64 build.
> Another concern is, IA64 supports atomic bitops with different width, 
> just
> like x86 while long is double size of integer on IA64. If the similar
> approach in this patch is used in other common places, it will add
> unnecessary size to xen/ia64.
Understood.

> > I think it would be a good idea to make a wiki page that covers the 
> > files
> > that are candidates for sharing. I know Jimi has investigated this 
> > subject...
> Agree.
Jimi, want to write down your thoughts and reply with the URL?

--
Hollis Blanchard
IBM Linux Technology Center


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel