[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0801071000390.17676@kivilampi-30.cs.helsinki.fi>
Date:	Mon, 7 Jan 2008 10:21:47 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Herbert Xu <herbert@...dor.apana.org.au>
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 Sun, 6 Jan 2008, Herbert Xu wrote:
> is definitely not a fast path.  If a function ends up being called
> just once the compiler will most likely inline it anyway, making the
> use of the keyword inline redundant.
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.
    net/ipv4/tcp_input.c:
      tcp_undo_cwr          |  -48
      tcp_try_undo_recovery |  -55
      tcp_ack               | -2941
     3 functions changed, 3044 bytes removed, diff: -3044
    
    net/ipv4/tcp_input.c:
      tcp_moderate_cwnd     |  +57
      tcp_fastretrans_alert | +2717
     2 functions changed, 2774 bytes added, diff: +2774
    
    net/ipv4/tcp_input.o:
     5 functions changed, 2774 bytes added, 3044 bytes removed, diff: -270
I'll probably force uninlining of it without tcp_moderate_cwnd noise and 
try a number of gcc versions.
-- 
 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
Powered by blists - more mailing lists