[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.