Venkat Subbiah wrote:Why are you trying to do this, anyway? This is a classic example of fairness hurting both performance and efficiency. Unbalanced distribution of a single IRQ gives superior performance. There are cases when this is a worthwhile tradeoff, but the network stack is not one of them. In the HPC world, people generally want to squeeze maximum performance out of CPU/cache/RAM so they just accept the imbalance because it performs better than balancing it, and irqbalance can keep things fair over longer intervals if that's important. In the realtime world, people generally bind everything they can to one or two CPUs, and bind their realtime applications to the remaining ones to minimize contention. Distributing your network interrupts in a round-robin fashion will make your computer do exactly one thing faster: heat up the room. -- Chris -
| Ingo Molnar | Re: containers (was Re: -mm merge plans for 2.6.23) |
| Greg Kroah-Hartman | [PATCH 009/196] Chinese: add translation of sparse.txt |
| holzheu | Re: [RFC/PATCH] Documentation of kernel messages |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Antonio Almeida | HTB accuracy for high speed |
