Re: softirq in pre3 and all linux ports

[Paul Mackerras <paulus@samba.org>]

Andrea Arcangeli writes:

> With pre3 there are bugs introduced into mainline that are getting
> extended to all architectures.
> 
> First of all nucking the handle_softirq from entry.S is wrong. ppc
> copied without thinking and we'll need to resurrect it too for example

Well, I object to the "without thinking" bit.  It seems to me that
code that raises a softirq without having either hard interrupts or
BHs disabled is buggy - why would you want to do that?  And if we do
want to allow that, shouldn't we put the check in raise_softirq or the
equivalent, to get the minimum latency?

> Fourth if the tasklet or softirq or bottom half hander is been marked
> running again because of another even (like a nested irq) the kernel can
> starve userspace too. (softirqs are much heavier than the irq handler so
> it can also live lockup much more easily this way)

Soft irqs should definitely not be much heavier than an irq handler,
if they are then we have implemented them wrongly somehow.

> So I recommend Linus merging this patch that fixes all the above
> mentioned bugs (the anti starvation/live lockup logic is called
> ksoftirqd):

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?

Regards,
Paul.