From: David McCullough <davidm@snapgear.com> To: Ihar Philips Filipau <filia@softhome.net> Cc: linux-kernel@vger.kernel.org Subject: Re: [uClinux-dev] Kernel 2.6 size increase - get_current()? Date: Thu, 24 Jul 2003 21:50:09 +1000 [thread overview] Message-ID: <20030724115009.GB16168@beast> (raw) In-Reply-To: <3F1F9887.5010703@softhome.net> Jivin Ihar Philips Filipau lays it down ... > David McCullough wrote: > > > >A general comment on the use of inline throughout the kernel. Although > >they may show gains on x86 platforms, they often perform worse on > >embedded processors with limited cache, as well as adding size. I > >can't see any way of coding around this though. As long as x86 is > >driving influence, other platforms will jut have to deal with it as > >best they can. > > > > Actually I'm victim on over inlining too. Was at least. > I was running some router on old Pentium's. I remember almost > dramatical drop of performance with newer kernels because of inlining in > net/*. But sure on Xeon P4 it boosts performance... > > Actually what I'm about. > We have classical situation when we have mess of representation and > intentions. > > Representation == 'inline', but intentions - 'inline or it will > break' _and_ 'inline - it runs faster'. > This obviously should be separated. The biggest problem I see is that the inlines are done in header files generally, and to stop them from inlining, you need to be able to switch from an inline to a prototype in the header file. The code from the header then needs to be added to a .o somewhere in the build for the case where inlines are stripped out. Other than providing non-critical inlines either on or off, I can't see the level approach working all that well. A combination of levels that work well on a few platforms may not work well at all on another. Still, just the ability to reduce the inlines would be very useful. Cheers, Davidm > even more. > > #define INLINE_LEVEL some_platform_specific_number > > --------- > > #define inline0 inline_always > > #if INLINE_LEVEL >= 1 > # define inline1 inline_always > #else > # define inline1 > #endif > ... > #if INLINE_LEVEL >= N > # define inlineN inline_always > #else > # define inlineN > #endif > > and so on, giving a platform chance to influence amount of inlining. > better to put it into config with defined by platform defaults. -- David McCullough, davidm@snapgear.com Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
next prev parent reply other threads:[~2003-07-24 11:35 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-07-24 8:27 Ihar "Philips" Filipau 2003-07-24 11:50 ` David McCullough [this message] [not found] <d2nx.4QV.15@gated-at.bofh.it> [not found] ` <dbTZ.5Z5.19@gated-at.bofh.it> 2003-07-25 15:37 ` Ihar "Philips" Filipau [not found] <cwQJ.3BO.29@gated-at.bofh.it> [not found] ` <cypH.5dM.35@gated-at.bofh.it> [not found] ` <cyza.5lN.13@gated-at.bofh.it> [not found] ` <cArg.74D.11@gated-at.bofh.it> 2003-07-24 8:13 ` Ihar "Philips" Filipau 2003-07-25 7:25 ` Denis Vlasenko 2003-07-25 18:36 ` bill davidsen -- strict thread matches above, loose matches on Subject: below -- 2003-07-23 18:46 Kernel 2.6 size increase Bernardo Innocenti 2003-07-23 20:22 ` [uClinux-dev] " David S. Miller 2003-07-23 20:27 ` Christoph Hellwig 2003-07-23 22:35 ` [uClinux-dev] Kernel 2.6 size increase - get_current()? Bernardo Innocenti 2003-07-23 22:37 ` Alan Cox 2003-07-23 23:00 ` Bernardo Innocenti 2003-07-24 5:06 ` David McCullough 2003-07-24 11:28 ` Alan Cox 2003-07-24 12:04 ` David McCullough 2003-07-24 14:48 ` Alan Cox 2003-07-25 18:25 ` bill davidsen 2003-07-24 15:30 ` Hollis Blanchard 2003-07-24 19:37 ` Alan Cox 2003-07-24 19:51 ` Hollis Blanchard 2003-07-24 21:20 ` J.A. Magallon 2003-07-25 4:22 ` Otto Solares 2003-07-25 14:38 ` Hollis Blanchard
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=20030724115009.GB16168@beast \ --to=davidm@snapgear.com \ --cc=filia@softhome.net \ --cc=linux-kernel@vger.kernel.org \ --subject='Re: [uClinux-dev] Kernel 2.6 size increase - get_current()?' \ /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).