Eric Dumazet wrote:
The problem is in established_get_next() and established_get_first() not
allowing softirq processing, while scanning a possibly huge hash table,
even if few sockets are hashed in.
As cond_resched_softirq() was added in linux-2.6.11, you probably *need*
to check the diffs
Chris Friesen a écrit :
Lee Revell wrote:
On 7/20/07, Chris Friesen <[EMAIL PROTECTED]> wrote:
We've run into an issue (on 2.6.10) where calling "lsof" triggers lost
packets on our server. Preempt is disabled, and NAPI is enabled.
Can you reproduce with a recent kernel? Lots of latency i
Lee Revell wrote:
On 7/20/07, Chris Friesen <[EMAIL PROTECTED]> wrote:
We've run into an issue (on 2.6.10) where calling "lsof" triggers lost
packets on our server. Preempt is disabled, and NAPI is enabled.
Can you reproduce with a recent kernel? Lots of latency issues have
been fixed sin
On 7/20/07, Chris Friesen <[EMAIL PROTECTED]> wrote:
We've run into an issue (on 2.6.10) where calling "lsof" triggers lost
packets on our server. Preempt is disabled, and NAPI is enabled.
Can you reproduce with a recent kernel? Lots of latency issues have
been fixed since then.
Lee
-
To u
We've run into an issue (on 2.6.10) where calling "lsof" triggers lost
packets on our server. Preempt is disabled, and NAPI is enabled.
It appears that for some reason the networking softirq is not being
handled in a timely fashion, which means that the rx ring buffer fills
up and packets o
5 matches
Mail list logo