| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [patch] bitops on irq_cpustat_t->__softirq_pending
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
|
|
|
| |
|
Home