Messages in this thread |  | | From | kuznet@ms2 ... | Subject | Re: [patch] softirq performance fixes, cleanups, 2.4.10. | Date | Fri, 28 Sep 2001 21:04:43 +0400 (MSK DST) |
| |
Hello!
> it does not, please read the code again. We iterate over all active bits > in the 'pending' bitmask.
OK.
> net_rx_action() stops spinning if 1) a jiffy has passed 2) 300 packets > have been processed. [the jiffy test is not completely accurate
It is. The break is forced not earlier than after one jiffie, but it may loop for up to 2 jiffies.
> 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.
Do not cheat yourself. 10 is more than 1 by order of magnitude. I would eat this argument if the limit was 2. :-)
> > 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.)
But I do not know what exactly to look for there.
Please, explain who exactly obtains an advantage of looping. net_rx_action()? Do you see drops in backlog? Actually, I could see a sense in your approach if you said something sort of: "I see drops in backlog, I want to increase it to 3000, but it breaks latency, so that let it remain 300, but instead I will make 10 loops". This would be sane justification at least.
net_tx_action()? It does not look critical.
Alexey - 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/
|  |