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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ