linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ihar \"Philips\" Filipau" <filia@softhome.net>
To: linux-kernel@vger.kernel.org
Subject: Re: [uClinux-dev] Kernel 2.6 size increase - get_current()?
Date: Fri, 25 Jul 2003 17:37:39 +0200	[thread overview]
Message-ID: <3F214EC3.9010804@softhome.net> (raw)
In-Reply-To: <dbTZ.5Z5.19@gated-at.bofh.it>

Hollis Blanchard wrote:

> I believe the point Alan was trying to make is not that we should have 
> more or less inlines, but we should have smarter inlines. I.E. don't 
> just inline a function to "make it fast"; think about the implications 
> (and ideally measure it, though I think that becomes problematic when so 
> many other factors can affect the benefit of a single inlined function). 
> The specific example he gave was inlining code on the fast path, while 
> accepting branch/cache penalties for non-inlined code on the slow path.
> 

   But you cannot make this kind of decisions universal.
   Some kind of compromise should be found between arch-mantainers and 
subsystem-mantainers.

   Or beat GCC developer hard so they finally will produce good
optimizing compiler ;-)

   Or ask all kernel developpers to work one hour per week on GCC 
optimization - I bet GCC will outperform everything else in industry in 
  less that one year ;-)))

   To remind: source of the problem is not inlines, problem is the 
compiler, which cannot read our minds yet and generate code we were 
expected it to generate.

P.S. Offtopic. As I see it Linux & Linus have made the decision of 
optimization. Linux after all is capitalismus creation: who has more 
money do control everything. Server market has more money - they do more 
work on kernel and they systems are not that far from developers' 
workstations - so Linux gets more and more server/workstation oriented. 
This will fit desktop market too - if your computer was made to run 
WinXP AKA exp(bloat) - it will be capable to run any OS. Linus repeating 
'small is beatiful' sounds more and more like crude joke...
As for embedded market - it is already in deep fork and far far away 
from vanilla kernels... Vanilla really not that relevant to real world...


       reply	other threads:[~2003-07-25 15:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
2003-07-25 20:46     ` OT: Vanilla not for embedded?! Re: Kernel 2.6 size increase - get_current()? Mike Fedyk
2003-07-25 20:43       ` Andre Hedrick
2003-07-27 11:57       ` Ihar "Philips" Filipau
2003-07-27 13:05         ` Francois Romieu
2003-07-24  8:27 [uClinux-dev] " Ihar "Philips" Filipau
2003-07-24 11:50 ` David McCullough
     [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=3F214EC3.9010804@softhome.net \
    --to=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).