agreed, apologies.
> BHs disabled is buggy - why would you want to do that? And if we do
tasklet_schedule
> want to allow that, shouldn't we put the check in raise_softirq or the
> equivalent, to get the minimum latency?
We should release the stack before running the softirq (some place uses
softirqs to release the stack and avoid overflows).
> Soft irqs should definitely not be much heavier than an irq handler,
> if they are then we have implemented them wrongly somehow.
ip + tcp are more intensive than just queueing a packet in a blacklog.
That's why they're not done in irq context in first place.
> ksoftirqd seems like the wrong solution to the problem to me, if we
> really getting starved by softirqs then we need to look at whether
> whatever is doing it should be a kernel thread itself rather than
> doing it in softirqs. Do you have a concrete example of the
> starvation/live lockup that you can describe to us?
I don't have gigabit ethernet so I cannot flood my boxes to death.
But I think it's real, and a softirq marking itself runnable again is
another case to handle without live lockups or starvation.
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/