Re: softirq in pre3 and all linux ports

[Paul Mackerras]

Andrea Arcangeli writes:

> We should release the stack before running the softirq (some place uses
> softirqs to release the stack and avoid overflows).

Well if they are relying on having a lot of stack available then those
places are buggy.  Once the softirq is made pending it can run at any
time that interrupts are enabled.  You can't rely on a softirq handler
having any more stack available than a hard interrupt handler has.

> 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.

Ah, ok, I misunderstood, I thought you were saying that that softirq
framework itself had a lot of overhead.

> 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.

As for the gigabit ethernet case, if we are having packets coming in
and generating hard interrupts at that sort of a rate then what we
really need is the sort of interrupt throttling that Jamal talked
about at the 2.5 kernel kickoff.

It seems to me that possibly softirqs are being used in some places
where a kernel thread would be more appropriate.  Instead of making
softirqs use a kernel thread, I think it would be better to find the
places that should use a thread and make them do so.  Softirqs are
still after all interrupt handlers (ones that run at a lower priority
than any hardware interrupt) and should be treated as such.

Paul.