linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 [uClinux-dev] Kernel 2.6 size increase - get_current()? 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 \
    /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
Be 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).