RE: CONFIG_IRQBALANCE for AMD64?

["Martin J. Bligh" <mbligh@aracnet.com>]

>> On Fri, May 28, 2004 at 10:46:18AM -0700, Martin J. Bligh wrote:
>>> 
>>> Personally, I find the argument that it's hardware-specific control
> code
>>> a much better reason for it to belong in the kernel.
>> 
>> Is it really hardware specific ??
> 
> I think automatic IRQ binding business should belong to the user-level;
> it can use generic statistics, application, or platform configuration
> knowledge.
> 
> The kernel-level should have some simple chipset model, such as lowest
> priority delivery mode with finer granularity of control. The kirqd at
> this point, is doing automatic IRQ binding business as well today,
> although it does not literally bind them. So I think we need to remove
> that part of code from kirqd. 

My personal feeling is that we can't get to happen from userspace what 
really needs to happen .... but we're going about this ass-backwards.
Instead of starting with a solution, and seeing what we can wedge into
it ... what do we actually want to do?

Here's my start at a list ... I'm sure it's woefully incomplete.

1. Utilize all CPUs roughly evenly for IRQ processing load (anything that's
not measured by the scheduler at least, because it's unfair to other 
processes). Also, we may well have more than 1 CPU's worth of traffic to
process in a large network server.

2. Provide some sort of cache-affinity for network interrupt processing,
which also helps us not get into out-of-order packet situations.

3. Utilize idle CPUs where possible to shoulder the load.

4. Provide such a solution for all architectures.

What else? I think we started doing this because of (1 & 2) mainline, 
especially as the P4 is moronically stupid by default but I know Dave 
Olien looked at 3 as well at some point past. 

ISTR one of the objections to the in-kernel stuff was that the way it
calculated costs was to look only at the in_interrupt() part of the
processing ... does the backend stuff get accounted currently to the
poor sucker who is currently running, in the same was as the interrupt?

Whatever we do ... all arches are going to need to provide a way to direct
interrupts to a certain CPU, or group thereof. Can they all do that already?
I'll confess to not having looked at non-i386 arches. And are others as
brain damaged as the P4? or do they do something round-robin by default?

M.