Messages in this thread | | | Date | Tue, 20 May 2003 10:21:58 -0400 | From | Jeff Garzik <> | Subject | Re: userspace irq balancer |
| |
On Tue, May 20, 2003 at 09:07:41AM -0500, Andrew Theurer wrote: > On Tuesday 20 May 2003 01:40, David S. Miller wrote: > > From: Dave Hansen <haveblue@us.ibm.com> > > Date: 19 May 2003 23:36:23 -0700 > > > > I don't even think we can do that. That code was being integrated > > around the same time that our Specweb setup decided to go south on us > > and start physically frying itself. > > > > This gets more amusing by the second. Let's kill this code > > already. People who like the current algorithms can push > > them into the userspace solution. > > Remember this all started with some idea of "fairness" among cpus and very > little to do with performance. particularly on P4 with HT, where the first > logical cpu got all the ints and tasks running on that cpu were slower than > other cpus. This was in most cases the highest performing situation, -but- > it was unfair to the tasks running on cpu0. irq_balance fixed this with a > random target cpu that was in theory supposed to not change often enough to > preserve cache warmth. In practice is the target cpus changed too often > which thrashed cache and the HW overhead of changing the destination that > often was way way to high.
You call that a fix? ;-) I call that working around a bug.
If tasks run slower on cpuX than cpuY because of a heavier int load, that's the fault of the scheduler not the irqbalancer, be it in-kernel or userspace. If there's a lesser-utilized cpu the task needs to be migrated to that cpu from the irq-loaded one, when CPU accounting notices the kernel interrupt handling having an impact.
Jeff
- 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/
| |