[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK1hOcOkTS=fWtD8T-nWrqFbOOAoDC2dYncakpz53Y=wnXACeQ@mail.gmail.com>
Date: Tue, 27 Oct 2015 16:17:34 +0100
From: Denys Vlasenko <vda.linux@...glemail.com>
To: Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Oleg Nesterov <oleg@...hat.com>
Subject: Re: Inline hunt results for 4.3.0-rc1
On Tue, Oct 27, 2015 at 3:55 PM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
> On Tue, Oct 27, 2015, at 15:32, Denys Vlasenko wrote:
>> I have created a set of semi-automated scripts which look for
>> large inlines in the kernel.
>>
>> Recently I taught it to even generate "git format-patch" patches
>> (unfortunately, only for inlines in *.c files, not *.h),
>> and here are they for 4.3.0-rc1 - i.e. current Linus tree.
>>
>> Submitting 300+ patches separately would amount to spamming,
>> instead I encourage people to take a look at the patches
>> on the Web:
>>
>> http://busybox.net/~vda/inline_hunt/4.3.0-rc1/
>> http://busybox.net/~vda/inline_hunt/4.3.0-rc1/README
>>
>> and in particular, at the set of most juicy patches, each of which
>> shaves off more than 1000 bytes off its *.c module:
>>
>> http://busybox.net/~vda/inline_hunt/4.3.0-rc1/patch_saves1000/
>
> Does gcc -finline-limit=2000 somehow has the same effect?
I'm afraid that's not a solution.
Any compiler-option-based fix would only work for inlines in *.c
files, but at the same time it would replicate inlines in *.h files
many times (once per module which calls the "auto-deinlined" inline).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists