From: Eric Dumazet <dada1@cosmosbay•com>
To: Rick Jones <rick.jones2@hp•com>
Cc: netdev@oss•sgi.com, "David S. Miller" <davem@redhat•com>,
Robert Olsson <Robert.Olsson@data•slu.se>
Subject: Re: [PATCH] Add prefetches in net/ipv4/route.c
Date: Fri, 29 Jul 2005 19:57:35 +0200 [thread overview]
Message-ID: <42EA6E0F.8060705@cosmosbay.com> (raw)
In-Reply-To: <42EA6202.703@hp.com>
Rick Jones a écrit :
> Robert Olsson wrote:
>
>> Eric Dumazet writes:
>>
>> > I have no profiling info for this exact patch, I'm sorry David.
>> > On a dual opteron machine, this thing from ip_route_input() is very
>> expensive :
>> > > RT_CACHE_STAT_INC(in_hlist_search);
>> > > ip_route_input() use a total of 3.4563 % of one cpu, but this
>> 'increment' takes 1.20 % !!!
>>
>> Very weird if the statscounter taking a third of ip_route_input.
>>
>> > Sometime I wonder if oprofile can be trusted :(
>> > > Maybe we should increment a counter on the stack and do a final
>> > if (counter != 0)
>> > RT_CACHE_STAT_ADD(in_hlist_search, counter);
>>
>> My experiences from playing with prefetching eth_type_trans in this
>> case. One must look in the total performance not just were the
>> prefetching is done. In this case I was able to get eth_type_trans
>> down in the profile list but other functions increased so performance
>> was the same or lower. This needs to be sorted out...
>
>
> How many of the architectures have PMU's that can give us cache miss
> statistics? Itanium does, and can go so far as to tell us which
> addresses and instructions are involved - do the others?
>
> That sort of data would seem to be desirable in this sort of situation.
>
> rick jones
>
>
oprofile on AMD64 can gather lots of data, DATA_CACHE_MISSES for example...
But I think I know what happens...
nm -v /usr/src/linux/vmlinux | grep -5 rt_cache_stat
ffffffff804c6a80 b rover.5
ffffffff804c6a88 b last_gc.2
ffffffff804c6a90 b rover.3
ffffffff804c6a94 b equilibrium.4
ffffffff804c6a98 b ip_fallback_id.7
ffffffff804c6aa0 B rt_cache_stat
ffffffff804c6aa8 b ip_rt_max_size
ffffffff804c6aac b ip_rt_debug
ffffffff804c6ab0 b rt_deadline
So rt_cache_stat (which is a read only pointer) is in the middle of a hot cache line (some parts of it are written over and over), that
probably ping pong between CPUS.
Time to provide a patch to carefully place all the static data from net/ipv4/route.c into 2 parts : mostly readonly, and others... :)
Eric
next prev parent reply other threads:[~2005-07-29 17:57 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-11 21:15 [TG3]: Add hw coalescing infrastructure David S. Miller
2005-05-11 21:17 ` Michael Chan
2005-05-12 2:28 ` David S. Miller
2005-05-12 7:53 ` Robert Olsson
2005-06-22 15:25 ` [TG3]: About " Eric Dumazet
2005-06-22 19:03 ` Michael Chan
2005-07-04 21:22 ` Eric Dumazet
2005-07-04 21:26 ` David S. Miller
2005-07-04 21:39 ` Eric Dumazet
2005-07-04 21:49 ` David S. Miller
2005-07-04 22:31 ` Eric Dumazet
2005-07-04 22:47 ` David S. Miller
2005-07-04 22:55 ` Eric Dumazet
2005-07-04 22:57 ` Eric Dumazet
2005-07-04 23:01 ` David S. Miller
2005-07-05 7:38 ` [PATCH] loop unrolling in net/sched/sch_generic.c Eric Dumazet
2005-07-05 11:51 ` Thomas Graf
2005-07-05 12:03 ` Thomas Graf
2005-07-05 13:04 ` Eric Dumazet
2005-07-05 13:48 ` Thomas Graf
2005-07-05 15:58 ` Eric Dumazet
2005-07-05 17:34 ` Thomas Graf
2005-07-05 21:22 ` David S. Miller
2005-07-05 21:33 ` Thomas Graf
2005-07-05 21:35 ` David S. Miller
2005-07-05 23:16 ` Eric Dumazet
2005-07-05 23:41 ` Thomas Graf
2005-07-05 23:45 ` David S. Miller
2005-07-05 23:55 ` Thomas Graf
2005-07-06 0:32 ` Eric Dumazet
2005-07-06 0:51 ` Thomas Graf
2005-07-06 1:04 ` Eric Dumazet
2005-07-06 1:07 ` Thomas Graf
2005-07-06 0:53 ` Eric Dumazet
2005-07-06 1:02 ` Thomas Graf
2005-07-06 1:09 ` Eric Dumazet
2005-07-06 12:42 ` Thomas Graf
2005-07-07 21:17 ` David S. Miller
2005-07-07 21:34 ` Thomas Graf
2005-07-07 22:24 ` David S. Miller
[not found] ` <42CE22CE.7030902@cosmosbay.com>
2005-07-08 7:30 ` David S. Miller
2005-07-08 8:19 ` Eric Dumazet
2005-07-08 11:08 ` Arnaldo Carvalho de Melo
2005-07-12 4:02 ` David S. Miller
2005-07-05 21:26 ` David S. Miller
2005-07-28 15:52 ` [PATCH] Add prefetches in net/ipv4/route.c Eric Dumazet
2005-07-28 19:39 ` David S. Miller
2005-07-28 20:56 ` Eric Dumazet
2005-07-28 20:58 ` David S. Miller
2005-07-28 21:24 ` Eric Dumazet
2005-07-28 22:44 ` David S. Miller
2005-07-29 14:50 ` Robert Olsson
2005-07-29 17:06 ` Rick Jones
2005-07-29 17:44 ` Robert Olsson
2005-07-29 17:57 ` Eric Dumazet [this message]
2005-07-29 18:25 ` Rick Jones
2005-07-31 3:52 ` David S. Miller
[not found] ` <42EDDA50.4010405@cosmosbay.com>
2005-08-01 15:39 ` David S. Miller
2005-07-31 3:51 ` David S. Miller
2005-07-31 3:44 ` David S. Miller
2005-07-04 23:00 ` [TG3]: About hw coalescing infrastructure David S. Miller
2005-07-05 16:14 ` Eric Dumazet
2005-07-04 22:47 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42EA6E0F.8060705@cosmosbay.com \
--to=dada1@cosmosbay$(echo .)com \
--cc=Robert.Olsson@data$(echo .)slu.se \
--cc=davem@redhat$(echo .)com \
--cc=netdev@oss$(echo .)sgi.com \
--cc=rick.jones2@hp$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox