On Tue, Oct 27, 2015, at 16:17, Denys Vlasenko wrote: > On Tue, Oct 27, 2015 at 3:55 PM, Hannes Frederic Sowa > <han...@stressinduktion.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.
Ok, thank you. > 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). Do your patches also detect functions which are in Header files with static inline and we take their address often? Maybe dst_output(_sk) could be an example? Bye, Hanes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/