| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ppc-devel
Re: [XenPPC] [PATCH] Enable SMP and IPIs
On Oct 24, 2006, at 9:15 PM, Amos Waterland wrote:
On Tue, Oct 24, 2006 at 05:54:47AM -0400, Jimi Xenidis wrote:
On Oct 24, 2006, at 12:22 AM, Amos Waterland wrote:
Note that the flurry of IPIs generated by domain creation seems to
be a waste of time. Xen on x86 doesn't actually to do anything in
response to them, so I have made Xen on PPC properly deliver the
event check but then do nothing as well. Comments?
What do you think we should be doing in response to these event check
IPIs?
It seems to be used to force a preemption event on a CPU.
The particular use is probably to wake CPUs napping in the idle
domain to "raise_softirq".
However, I would think that this could have been done with a "call
function".
I thought that there were hopes of improving interactivity of
single-cpu systems ...
Not sure what your point is here. I don't see how any IPI can do that.
I know this is RFC, and you know I'm a bug fan of BUG(), but
eventually I'd expect:
BUG_ON(!action)
if (!action)
return -ENOMEM
I think your comments here are predicated on the assumption that BUG
macros become noops when not compiling with debug. That is not the
case
in Xen, so I thought it was a waste of time to put in extra code. Do
you think it might someday not be the case?
I personally consider BUG() to be more a developer tool and in
general should not be considered a no-return, however the Xen
maintainers do not agree with this, but I'd like to see it reflected
in our code.
However, you raise an interesting issue where I would have thought
that the caller of request_irq() would check and BUG/panic. Linux
uses this as a standard service and we are using it as a
compatibility function for the mpic.c driver that does _not_ check
the return value.
-JX
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
|
|
| |
|
Home