Re: posible latency issues in seq_read

2007-07-23 Thread Chris Friesen
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

Re: posible latency issues in seq_read

2007-07-20 Thread Eric Dumazet
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

Re: posible latency issues in seq_read

2007-07-20 Thread Chris Friesen
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

Re: posible latency issues in seq_read

2007-07-20 Thread Lee Revell
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

posible latency issues in seq_read

2007-07-20 Thread Chris Friesen
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