> So if you can't handle the IPI when you get it, set a flag and trap on the
> next sti. It certainly sounds like broken hardware to me and it can be
> worked around, can't it ?
We should not do such a hack in a performance critical area.
> Maybe we should have a version of smp_call_function that uses softirqs
> (unless those are broken on sparc as well ;) ) and use the old version for
> the very performance-sensitive parts only ?
>
> Putting all tests for smp_call_function in the timer interrupt code doesn't
> make any sense at all to me.
smp_call_function is only used in the slab code. I was under the impression
it wasnt going to be used in generic code. In fact I removed it completely
from the sparc32 tree.
Anton
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
