[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