netdev - Re: [RFC][PATCH] Turn part of SNMP accounting macros into functions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48B58A65.5060906@openvz.org>
Date:	Wed, 27 Aug 2008 21:09:57 +0400
From:	Pavel Emelyanov <xemul@...nvz.org>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
CC:	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [RFC][PATCH] Turn part of SNMP accounting macros into functions

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.
> 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html