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