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 [RFC PATCH 0/8]: uninline & uninline 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 \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).