you brought a very funny case ;), agreed! certainly if it's ksoftirqd
with NAPI that is causing the irq move to the next cpu you don't want to
migrate it to the next cpu ksoftirqd will keep following it, rounding
back and forth across all idle cpus (assuming a firwall with many idle
cpus). So basically you're saying that we've to change it to idle() ||
== ksoftirqd (i'll fix it thanks!). The additional check should avoid
the misbehaviour. In 2.4 normally the softirq (of course w/o NAPI) are
served in irq context so we didn't face this yet.
But it doesn't change my basic argument about this topic, that there's
no way in userspace to do anything remotely as accurate as that to boost
system performance to the maximum, especially on big systems. My current
algorithm was a minimal attempt to do something better than the static
(or almost static) bindings with all the info we have in kernel (that
userspace could never use efficiently on a timely basis).
Andrea
-
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/