netdev - Re: [PATCH 3/4] [XFRM]: Kill some bloat

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20080107100201.GC24258@gondor.apana.org.au>
Date:	Mon, 7 Jan 2008 21:02:01 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
Cc:	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	paul.moore@...com, latten@...ibm.com
Subject: Re: [PATCH 3/4] [XFRM]: Kill some bloat

On Mon, Jan 07, 2008 at 10:21:47AM +0200, Ilpo Järvinen wrote:
>
> Unexpected enough, even this logic seems to fail in a way with my gcc, I'm 
> yet to study it closer but it seems to me that e.g., uninlining only once 
> called tcp_fastretrans_alert is worth of at least 100 bytes (note that 
> it's not inlined by us, gcc did it all by itself)! Otherwise I'd fail to 
> understand why I got -270 bytes from uninlining tcp_moderate_cwnd which is 
> only 57 bytes as unlined with three call sites.

Yeah I've studied this effect over the years in my maintainence of
the dash shell where size is paramount :) 

On x86-32 due to the scarcity of registers local variables often end
up on the stack.  In that case gcc will usually refer to them via %ebp
or %esp.  It just so happens that if the offset is within 128 bytes
of the base register then the instruction can encode the offset with
just a single byte.  However, if it exceeds 128 bytes the instruction
will take 4 bytes to encode the offset.

Since bigger functions are more likely to go over that threshold,
this explains some instances where uninlining ends up being bigger.

There are other similar issues, such as the branch offset which also
goes from 1 byte to 4 when you go over 128 bytes.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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