Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> Very good question, but honestly I really dont see why it was there at the
> first place :
It was there because someone went through this file and robotically
replaced all conditional read barriers with rcu_dereference, even when
it made zero sense.
B
David Miller a écrit :
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 08 Jan 2008 07:11:30 +0100
@@ -288,15 +288,15 @@ static struct rtable *rt_cache_get_first(struct seq_file
*seq)
static struct rtable *rt_cache_get_next(struct seq_file *seq, struct rtable *r)
{
- struct rt_cach
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 08 Jan 2008 07:11:30 +0100
> @@ -288,15 +288,15 @@ static struct rtable *rt_cache_get_first(struct
> seq_file *seq)
>
> static struct rtable *rt_cache_get_next(struct seq_file *seq, struct rtable
> *r)
> {
> - struct rt_cache_iter_state *
David Miller a écrit :
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Mon, 7 Jan 2008 19:30:02 +0100
I noticed "ip route list cache x.y.z.t" can be *very* slow.
While strace-ing -T it I also noticed that first part of route cache is
fetched quite fast :
...
The following patch corrects this p
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Mon, 7 Jan 2008 19:30:02 +0100
> I noticed "ip route list cache x.y.z.t" can be *very* slow.
>
> While strace-ing -T it I also noticed that first part of route cache is
> fetched quite fast :
...
> The following patch corrects this performance/latency
I noticed "ip route list cache x.y.z.t" can be *very* slow.
While strace-ing -T it I also noticed that first part of route cache is
fetched quite fast :
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{"p\0\0\0\30\0\2\0\254i\202
GXm\0\0\2 \0\376\0\0\2\0\2\0
