From: Pavel Emelyanov <xemul@openvz.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Cc: Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: [RFC][PATCH] Turn part of SNMP accounting macros into functions
Date: Wed, 27 Aug 2008 21:09:57 +0400 [thread overview]
Message-ID: <48B58A65.5060906@openvz.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0808271948000.4539@wrl-59.cs.helsinki.fi>
Ilpo Järvinen wrote:
> On Wed, 27 Aug 2008, Pavel Emelyanov wrote:
>
>> After turning IP_XXX_STATS, TCP_XXX_STATS and NET_XXX_STATS from
>> macros into functions the net/ipv4/built-in.o shrank significantly:
>>
>> add/remove: 14/0 grow/shrink: 0/67 up/down: 482/-2246 (-1764)
>>
>> Turning the CONFIG_NET_NS option on makes this shrink even larger:
>>
>> add/remove: 14/0 grow/shrink: 0/67 up/down: 478/-2646 (-2168)
>
> Is there perhaps some DEBUG related config that could bloat these numbers?
Nope. I only had a DEBUG_BUG_VERBOSE turned on in my experiments.
> ...I didn't come up with anything obvious when I quickly looked the
> definations but I might have missed something.
Well, looking at NET_INC_STATS_BH as a function
000000a9 <NET_INC_STATS_BH>:
a9: 8b 40 74 mov 0x74(%eax),%eax
ac: 64 8b 0d 00 00 00 00 mov %fs:0x0,%ecx
af: R_386_32 per_cpu__cpu_number
b3: f7 d0 not %eax
b5: 8b 04 88 mov (%eax,%ecx,4),%eax
b8: ff 04 90 incl (%eax,%edx,4)
bb: c3 ret
I guess that the heaviest thing there is smp_processor_id, which
is 7 bytes out of 19 total.
Actually the complete bloat-o-meter.sh output showed that there were
~10 functions, that became 8 bytes liter, ~10 that became 12-16 bytes
liter and so on. This makes me think, that the code in the macro
itself is pretty small, but is used widely in the networking code,
and this spread makes such a big bloat.
>> So the question is - what was the reason to keep those as macros?
>> I thought about the possible performance questions, but netperf
>> didn't show any (I admit I just cannot cook it properly).
>
> IMHO, even if there would be some performance regression, only the
> most hottest paths would need to have it inlined, the rest would be
> quite fine having it as a function.
OK, thanks Ilpo. I'll then look at how to make this more beautiful
and send to Dave.
> --
> i.
>
next prev parent reply other threads:[~2008-08-27 17:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-27 16:31 [RFC][PATCH] Turn part of SNMP accounting macros into functions Pavel Emelyanov
2008-08-27 16:41 ` Stephen Hemminger
2008-08-27 16:56 ` Ilpo Järvinen
2008-08-27 17:09 ` Pavel Emelyanov [this message]
2008-08-27 17:58 ` Ilpo Järvinen
2008-08-27 17:07 ` Eric Dumazet
2008-08-28 11:12 ` Pavel Emelyanov
2008-08-28 12:51 ` Eric Dumazet
2008-08-28 12:54 ` Pavel Emelyanov
2008-08-29 7:01 ` Herbert Xu
2008-08-29 7:29 ` Pavel Emelyanov
2008-08-29 12:57 ` Christoph Lameter
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=48B58A65.5060906@openvz.org \
--to=xemul@openvz.org \
--cc=ilpo.jarvinen@helsinki.fi \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).