[lkml]   [2001]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] softirq performance fixes, cleanups, 2.4.10.

> it does not, please read the code again. We iterate over all active bits
> in the 'pending' bitmask.


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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:03    [W:0.083 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site