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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
