LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
David Miller <davem@davemloft.net>,
Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: Re: [RFC PATCH 0/8]: uninline & uninline
Date: Sat, 23 Feb 2008 12:11:49 +0200 (EET) [thread overview]
Message-ID: <Pine.LNX.4.64.0802231004450.29504@kivilampi-30.cs.helsinki.fi> (raw)
In-Reply-To: <20080223000220.e9229c99.akpm@linux-foundation.org>
On Sat, 23 Feb 2008, Andrew Morton wrote:
> On Wed, 20 Feb 2008 15:47:10 +0200 "Ilpo J__rvinen" <ilpo.jarvinen@helsinki.fi> wrote:
>
> > -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR
>
> This is a surprise.
It surprised me as well, there were something like 10 bytes I just
couldn't explain in IS_ERR size (kernel/uninlined.c: IS_ERR | +25). I was
to look into it deeper but didn't have the .o's at hand right away, not so
trivial to store results of 5000+ build results except some carefully
picked textual output :-)... Hmm, I'll add logging for the disassembly of
the uninlined stuff into the next run, that won't cost too much...
> I expect that the -mm-only
> profile-likely-unlikely-macros.patch is the cause of this and mainline
> doesn't have this problem.
Ahaa, this explain it, I suspected that there was something (un)likely
related elsewhere as well, no wonder why I couldn't reproduce the 25 bytes
result in my quick copy-pasted non-kernel test...
> If true, then this likely/unlikely bloat has probably spread into a lot of
> your other results and it all should be redone against mainline, sorry :(
It isn't that troublesome to redo them, it's mainly automatic combined
with impatient waiting from my behalf :-)... The spreading problem is
probably true, to some extent. I did some runs also with carefully
selected CONFIG.*DEBUG.* off under include/net/ earlier, in general it
made very little difference, if something bloats, it usually does that
regardless of .config. There are probably couple of exceptions when the
size is on the boundary where it's very close of being useful to uninline
it.
One interesting thing in there was that the largest offenders are quite
small per call-site but due to vast number of them even a small benefit
buys off a lot in kernel wide results. I suspect the differences due to
(un)likely will be negligle, because the IS_ERR with all its trivialness
is now mostly -15, so anything clearly larger than that will likely still
be a win x n (where n is quite large).
Anyway, I'll see when I get the new set of tests running... :-) I'd prefer
with CONFIG.*DEBUG off to get larger picture about non-debug builds too
(especially the scatterlist.h things interest me a lot), do you think that
would do as well?
Thanks for your comments, I found them very useful.
--
i.
next prev parent reply other threads:[~2008-02-23 10:12 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-20 13:47 Ilpo Järvinen
2008-02-20 13:47 ` [RFC PATCH 1/8] [NET]: uninline skb_put, de-bloats a lot Ilpo Järvinen
2008-02-20 13:47 ` [RFC PATCH 2/8] [NET]: uninline skb_pull, " Ilpo Järvinen
2008-02-20 13:47 ` [RFC PATCH 3/8] [NET]: uninline dev_alloc_skb, " Ilpo Järvinen
2008-02-20 13:47 ` [RFC PATCH 4/8] [NET]: uninline skb_push, " Ilpo Järvinen
2008-02-20 13:47 ` [RFC PATCH 5/8] [NET]: uninline dst_release Ilpo Järvinen
2008-02-20 13:47 ` [RFC PATCH 6/8] [NET]: uninline skb_trim, de-bloats Ilpo Järvinen
2008-02-20 13:47 ` [RFC PATCH 7/8] [SCTP]: uninline sctp_add_cmd_sf Ilpo Järvinen
2008-02-20 13:47 ` [RFC PATCH 8/8] Jhash in too big for inlining, move under lib/ Ilpo Järvinen
2008-02-23 8:02 ` Andrew Morton
2008-02-23 10:05 ` Ilpo Järvinen
2008-02-23 18:21 ` Andrew Morton
2008-02-23 13:06 ` Andi Kleen
2008-02-20 22:16 ` [RFC PATCH 7/8] [SCTP]: uninline sctp_add_cmd_sf Vlad Yasevich
2008-02-20 22:34 ` Ilpo Järvinen
2008-02-21 15:27 ` Vlad Yasevich
2008-02-20 16:19 ` [RFC PATCH 3/8] [NET]: uninline dev_alloc_skb, de-bloats a lot Jan Engelhardt
2008-02-20 16:27 ` Patrick McHardy
2008-02-20 16:30 ` Jan Engelhardt
2008-02-20 22:18 ` Ilpo Järvinen
2008-03-12 15:27 ` Ilpo Järvinen
2008-02-20 13:54 ` [RFC PATCH 1/8] [NET]: uninline skb_put, " Patrick McHardy
2008-02-20 13:57 ` Eric Dumazet
2008-02-23 8:02 ` [RFC PATCH 0/8]: uninline & uninline Andrew Morton
2008-02-23 10:11 ` Ilpo Järvinen [this message]
2008-02-23 13:15 ` Andi Kleen
2008-02-23 18:06 ` Ilpo Järvinen
2008-02-23 18:55 ` Andrew Morton
2008-02-23 19:58 ` Hua Zhong
2008-02-23 21:02 ` Andi Kleen
2008-02-27 19:08 ` profile-likely patch (was " Valdis.Kletnieks
-- strict thread matches above, loose matches on Subject: below --
2008-02-20 13:35 Ilpo Järvinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0802231004450.29504@kivilampi-30.cs.helsinki.fi \
--to=ilpo.jarvinen@helsinki.fi \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--subject='Re: [RFC PATCH 0/8]: uninline & uninline' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).