--
On Tue, 28 Aug 2007, Masayuki Nakagawa wrote:
> > On Sat, 2007-06-23 at 08:25 -0400, Steven Rostedt wrote:
> >
> >> --- linux-2.6.21.orig/net/ipv4/tcp_ipv4.c 2007-06-17
> >> 17:19:02.000000000 +0200
> >> +++ linux-2.6.21/net/ipv4/tcp_ipv4.c 2007-06-17 17:20:27.000000000 +0200
> >> @@ -2033,7 +2033,12 @@ static void *established_get_first(struc
> >> struct tcp_iter_state* st = seq->private;
> >> void *rc = NULL;
> >>
> >> - for (st->bucket = 0; st->bucket < tcp_hashinfo.ehash_size;
> >> ++st->bucket) {
> >>
> >> The above is a linear search through out a very large array, where most
> >> of the items are NULL. I believe it was Lee that noticed this creating
> >> a large latency. This was back in 2.6.14. I'll check to see if this
> >> still is a source of latency with the latest kernels.
> >
> > It looks fairly generic, is it a latency that could be fix the same way
> > up stream?
> >
> > Daniel
> >
> Hi Steven,
>
> I believe that we should push the following patch to upstream(netdev).
> (This is a patch which extracted a part of the hash code from real-time
> patch.)
> How do you think?
>
Hi Masayuki,
I really need to investigate if this is even still needed. This code was
originally added when a bh lock was held for the entire for loop. I see
that it is done per entry now. I'll take a look to see if there's a
better way to do this.
Thanks for bringing this back to the fore front.
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
