On Tuesday 20 May 2003 05:22 pm, David S. Miller wrote:
> From: Andrew Morton <akpm@digeo.com>
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri May 23 2003 - 22:00:44 EST