From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Hannes Frederic Sowa <hannes@stressinduktion.org>,
netdev@vger.kernel.org
Subject: Re: [net-next PATCH 3/4] net: avoid false perf interpretations in frag code
Date: Thu, 25 Apr 2013 12:57:08 +0200 [thread overview]
Message-ID: <1366887428.26911.542.camel@localhost> (raw)
In-Reply-To: <1366847307.8964.89.camel@edumazet-glaptop>
On Wed, 2013-04-24 at 16:48 -0700, Eric Dumazet wrote:
> On Wed, 2013-04-24 at 17:48 +0200, Jesper Dangaard Brouer wrote:
> > The compiler make us misinterpret performance issues in the frag code,
> > because its auto inlining functions. Lets instead do explicit
> > inlining to make this situation obvious to the programmer.
> >
> > The function inet_frag_find() get the perf blame, because auto
> > inlining of the functions inet_frag_create(), inet_frag_alloc() and
> > inet_frag_intern().
> >
> > My solution is to explicit inline inet_frag_alloc() and
> > inet_frag_intern(), but explicitly "noinline" inet_frag_create(),
> > in-order to make it explicit to the performance engineer, that
> > creation phase is a bottleneck. Then, when reading the code the
> > programmer should notice the inline, and see the bottleneck is really
> > located in inet_frag_intern().
> >
> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > ---
>
> There is no way we add inline/noinline attributes to help developers to
> use performance tools.
I take that as a NACK
Would we add the "inlines" only to the code, to make it clear what is
happening in the code?
next prev parent reply other threads:[~2013-04-25 12:42 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-24 15:47 [net-next PATCH 0/4] net: frag patchset for fixing LRU scalability issue Jesper Dangaard Brouer
2013-04-24 15:48 ` [net-next PATCH 1/4] Revert "inet: limit length of fragment queue hash table bucket lists" Jesper Dangaard Brouer
2013-04-25 0:00 ` Eric Dumazet
2013-04-25 13:10 ` Jesper Dangaard Brouer
2013-04-25 13:58 ` David Laight
2013-05-02 7:59 ` Jesper Dangaard Brouer
2013-05-02 15:16 ` Eric Dumazet
2013-05-03 9:15 ` Jesper Dangaard Brouer
2013-04-24 15:48 ` [net-next PATCH 2/4] net: increase frag hash size Jesper Dangaard Brouer
2013-04-24 22:09 ` Sergei Shtylyov
2013-04-25 10:13 ` Jesper Dangaard Brouer
2013-04-25 12:13 ` Sergei Shtylyov
2013-04-25 19:11 ` David Miller
2013-04-24 23:48 ` Eric Dumazet
2013-04-25 3:26 ` Hannes Frederic Sowa
2013-04-25 19:52 ` [net-next PATCH V2] " Jesper Dangaard Brouer
2013-04-29 17:44 ` David Miller
2013-04-24 15:48 ` [net-next PATCH 3/4] net: avoid false perf interpretations in frag code Jesper Dangaard Brouer
2013-04-24 23:48 ` Eric Dumazet
2013-04-24 23:54 ` David Miller
2013-04-25 10:57 ` Jesper Dangaard Brouer [this message]
2013-04-25 19:13 ` David Miller
2013-04-24 15:48 ` [net-next PATCH 4/4] net: frag LRU list per CPU Jesper Dangaard Brouer
2013-04-25 0:25 ` Eric Dumazet
2013-04-25 2:05 ` Eric Dumazet
2013-04-25 14:06 ` Jesper Dangaard Brouer
2013-04-25 14:37 ` Eric Dumazet
2013-04-25 13:59 ` Jesper Dangaard Brouer
2013-04-25 14:10 ` Eric Dumazet
2013-04-25 14:18 ` Eric Dumazet
2013-04-25 19:15 ` Jesper Dangaard Brouer
2013-04-25 19:22 ` Eric Dumazet
2013-04-24 16:21 ` [net-next PATCH 0/4] net: frag patchset for fixing LRU scalabilityissue David Laight
2013-04-25 11:39 ` Jesper Dangaard Brouer
2013-04-25 12:57 ` David Laight
2013-04-24 17:27 ` [net-next PATCH 0/4] net: frag patchset for fixing LRU scalability issue Hannes Frederic Sowa
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=1366887428.26911.542.camel@localhost \
--to=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=hannes@stressinduktion.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.