Messages in this thread | | | From | Paul Mackerras <> | Date | Wed, 20 Jun 2001 13:33:19 +1000 (EST) | Subject | Re: softirq in pre3 and all linux ports |
| |
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. - 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/
| |