From: David McCullough <email@example.com>
To: Ihar Philips Filipau <firstname.lastname@example.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)
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
> 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.
> even more.
> #define INLINE_LEVEL some_platform_specific_number
> #define inline0 inline_always
> #if INLINE_LEVEL >= 1
> # define inline1 inline_always
> # define inline1
> #if INLINE_LEVEL >= N
> # define inlineN inline_always
> # define inlineN
> 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, email@example.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 [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.firstname.lastname@example.org>
[not found] ` <dbTZ.5Z5.email@example.com>
2003-07-25 15:37 ` Ihar "Philips" Filipau
[not found] <cwQJ.3BO.firstname.lastname@example.org>
[not found] ` <cypH.5dM.email@example.com>
[not found] ` <cyza.5lN.firstname.lastname@example.org>
[not found] ` <cArg.74D.email@example.com>
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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).