Re: userspace irq balancer

[James Cleverdon]

On Tuesday 20 May 2003 05:22 pm, David S. Miller wrote:
>    From: Andrew Morton <[e-mail]>
>    Date: Tue, 20 May 2003 02:17:12 -0700
>
>    Concerns have been expressed that the /proc interface may be a bit racy.
>    One thing we do need to do is to write a /proc stresstest tool which
> pokes numbers into the /proc files at high rates, run that under traffic
> for a few hours.
>
> This issue is %100 independant of whether policy belongs in the
> kernel or not.  Also, the /proc race problem exists and should be
> fixed regardless.
>
>    Nobody has tried improving the current balancer.
>
> Policy does not belong in the kernel.  I don't care what algorithm
> people decide to use, but such decisions do NOT belong in the kernel.

You keep saying that, but suppose I want to try HW IRQ balancing using the TPR 
registers.  How could I do that from userspace?  And if I could, wouldn't the 
benefit of real time IRQ routing be lost?

It seems to me that only long term interrupt policy can be done from userland.  
Anything that does fast responses to fluctuating load must be inside the 
kernel.

At the moment we don't do any fast IRQ policy.  Even the original irq_balance 
only looked for idle CPUs after an interrupt was serviced.  However, suppose 
you had a P4 with hyperthreading turned on.  If an IRQ is to be delivered to 
the main thread but it is busy and its sibling is idle, why shouldn't we 
deliver the interrupt to the idle sibling?  They both share the same caches, 
etc, so cache warmth isn't a problem.

-- 
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com