Re: [patch] softirq performance fixes, cleanups, 2.4.10.

[Ingo Molnar]

On Fri, 28 Sep 2001 [e-mail] wrote:

> >  - removed 'mask' handling from do_softirq() - it's unnecessery due to the
> >    restarts. this further simplifies the code.
>
> Ingo, but this means that only the first softirq is handled.
> "mask" implements round-robin and this is necessary.

it does not, please read the code again. We iterate over all active bits
in the 'pending' bitmask. All softirqs that are active are handled. This
inner loop is repeated up to MAX_SOFTIRQ_RESTART times, if any softirq got
reactivated meanwhile.

> Also, you did not assure me that you interpret problem correctly.
> netif_rx() is __insensitive__ to latencies due to blocked softirq
> restarts. It stops spinning only when it becomes true cpu hog. [...]

(i suspect you meant net_rx_action().)

net_rx_action() stops spinning if 1) a jiffy has passed 2) 300 packets
have been processed. [the jiffy test is not completely accurate as it can
break out of the loop after a short amount of time, but that is a minor
issue.]

there is nothing sacred about the old method of processing NET_RX_SOFTIRQ,
then NET_TX_SOFTIRQ, then breaking out of do_softirq() (the mechanizm was
a bit more complex than that, but in insignificant ways). It's just as
arbitrary as 10 loops - with the difference that 10 loops perform better.

> And scheduling ksoftirqd is the only variant here.

scheduling ksoftirqd is the only variant once we have decided that
softirqs are a CPU hog and we want to make progress in non-irq contexts.
A single loop over softirqs is just as arbitrary as 10 loops, this all is
a matter of balancing.

> Most likely, your problem will disappear when you renice ksoftirqd
> to higher priority f.e. equal to priority of tux threads.

(no. see the previous mails.)

	Ingo