some comment after reading your softirq-2.4.10-A7.
> - softirq handling can now be restarted N times within do_softirq(), if a
> softirq gets reactivated while it's being handled.
is this really necessary after introducing the unwakeup logic? What do
you get if you allow at max 1 softirq pass as before?
> - '[ksoftirqd_CPU0]' is confusing on UP systems, changed it to
> '[ksoftirqd]' instead.
"confusing" for you maybe, not for me, but I don't care about this one
anyways :).
> - simplified ksoftirqd()'s loop, it's both shorter and faster by a few
> instructions now.
only detail: ksoftirqd can show up as sleeping from /proc while it's
runnable but I don't think it's a problem and saving the state
clobbering is probably more sensible.
no other obvious issue, except I preferred to wait each ksoftirqd to
startup succesfully to be strictier and I'd also put an assert after
the schedule() to verify ksoftirqd is running in the right cpu.
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/