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.

  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).