[PATCH] update irq affinity mask when migrating irqs
Joel Schopp
jschopp at austin.ibm.com
Wed Mar 9 11:31:46 EST 2005
Olof Johansson wrote:
> On Tue, Mar 08, 2005 at 11:20:33AM -0600, Joel Schopp wrote:
>
>
>>The downside of calling this is it increases the path length and causes
>> ibm_get_xive to be called again. Usually slightly slower is a fine
>>tradeoff for more readable code, but in this case I would have left it
>>how it was. With all the cpus stopped it is best to be as fast as
>
>
> Is CPU removal really that performance critical a path? How long does
> a ibm_get_xive call take?
The part of it where we have all the cpus with interrupts disabled
running our high priority tasks is VERY performance critical. Look at
the __stop_machine_run() and stop_machine code. The rest of it is not
performance critical at all.
I couldn't tell you how long an ibm_get_xive call takes, and I suppose
it would vary from system to system. I doubt that adding a ibm_get_xive
call and a few other instructions would do much damage. Still, I'd hate
it to be the straw that broke the camel's back. The way we'd notice
such problems would make it painful to determine the root cause in the
field.
>
>
>>possible. Maybe this is still fast enough, but you'd have to test under
>>heavy load on a variety of systems to be sure.
>
>
> Please define "fast enough".
__stop_machine_run doesn't interfere with system operation. No buffers
gets overfilled, no interrupts get lost, no packets get dropped, etc.
More information about the Linuxppc64-dev
mailing list