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...
On Fri, Jul 25, 2003 at 05:37:39PM +0200, Ihar Philips Filipau wrote:
> 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...
Vanilla will be what people put into it. And I have seen more messages from
embedded people complaining, than actually doing and submitting patches for
merging.
So the embedded trees are a deep fork huh? Did you or anyone else do
anything to merge during 2.5?!
And now you see why there is a "deep" fork...
Where is the "deep" fork storaged, sounds interesting!
At lets it should buisness friendly.
-a
On Fri, 25 Jul 2003, Mike Fedyk wrote:
> On Fri, Jul 25, 2003 at 05:37:39PM +0200, Ihar Philips Filipau wrote:
> > 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...
>
> Vanilla will be what people put into it. And I have seen more messages from
> embedded people complaining, than actually doing and submitting patches for
> merging.
>
> So the embedded trees are a deep fork huh? Did you or anyone else do
> anything to merge during 2.5?!
>
> And now you see why there is a "deep" fork...
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Mike Fedyk wrote:
>
> Vanilla will be what people put into it. And I have seen more messages from
> embedded people complaining, than actually doing and submitting patches for
> merging.
>
> So the embedded trees are a deep fork huh? Did you or anyone else do
> anything to merge during 2.5?!
>
> And now you see why there is a "deep" fork...
>
Real-time stuff is a must - something like RTAI.
Things like Linux Trace Toolkit - soone or later you have to start
using them to tune performace.
Patches to remove mandatory (for 2.2/2.0) PCI/IDE support were pretty
common too.
Patch to shrink network hashes - norm of life.
Patch to kill PCI names database.
And this is only things I was using personally (and I remember about)
in my short 4 years carrier.
CONFIG_TINY - http://lwn.net/Articles/14186/ - got something like
this merged? - so I'm the first guy in the download queue on ftp.kernel.org!
Kernel heavily tuned for servers and workstations (read - modern PCs).
At my previous position company was using kernel prepared by Karim
Yaghmour and right now we using kernels from MontaVista.
Far from vanillas.
> embedded people complaining
Sure complaining.
For some reasons all "improvements" to kernel had lead to increase of
kernel size, not decrease. Strange, isn't it?
Ihar Philips Filipau <[email protected]> :
[...]
> Patches to remove mandatory (for 2.2/2.0) PCI/IDE support were pretty
> common too.
> Patch to shrink network hashes - norm of life.
> Patch to kill PCI names database.
> And this is only things I was using personally (and I remember about)
> in my short 4 years carrier.
Would you mind publishing the patches ?
> CONFIG_TINY - http://lwn.net/Articles/14186/ - got something like
> this merged? - so I'm the first guy in the download queue on ftp.kernel.org!
See CONFIG_EMBEDDED.
[...]
> For some reasons all "improvements" to kernel had lead to increase of
> kernel size, not decrease. Strange, isn't it?
No time for sarcasm here.
Regards
--
Ueimor
Francois Romieu wrote:
>> Patches to remove mandatory (for 2.2/2.0) PCI/IDE support were pretty
>>common too.
>> Patch to shrink network hashes - norm of life.
>> Patch to kill PCI names database.
>> And this is only things I was using personally (and I remember about)
>>in my short 4 years carrier.
>
> Would you mind publishing the patches ?
>
As I already answered privately - I do have them right now.
And those patches were not mine.
Most of them was collected right on lkml or from digests on lwn.net.
[ I was playing only with network code - and I was concerned with
performance more, than with image size. And had no luck achiving
something. ]
>
>> CONFIG_TINY - http://lwn.net/Articles/14186/ - got something like
>>this merged? - so I'm the first guy in the download queue on ftp.kernel.org!
>
>
> See CONFIG_EMBEDDED.
>
Okay. I have found it.
But I cannot find how it is used.
I have grepped thru 2.6.0-test0 - but I can find only entries in
defconfigs - but no mentions in .h/.c files.
What I'm missing?
And yes - this option doesn't work in 'make menuconfig'.
>> For some reasons all "improvements" to kernel had lead to increase of
>>kernel size, not decrease. Strange, isn't it?
>
> No time for sarcasm here.
>
Correct me if I'm wrong.
I was just poking around 'small is beatiful'.
P.S. To my earlier 'far from vanilla' comment (-x '.*' - to skip
.depend/.config/etc):
$ diff -urN -x '.*' ./linux-2.4.17 \
/opt/hardhat/devkit/lsp/ibm-walnut-ppc_405/linux-2.4.17_mvl21\
| wc -l
1128089
$
and more than 500 additional CONFIG_* parameters comparing to vanilla.
Ihar "Philips" Filipau wrote:
>
> P.S. To my earlier 'far from vanilla' comment (-x '.*' - to skip
> .depend/.config/etc):
> $ diff -urN -x '.*' ./linux-2.4.17 \
> /opt/hardhat/devkit/lsp/ibm-walnut-ppc_405/linux-2.4.17_mvl21\
> | wc -l
> 1128089
> $
> and more than 500 additional CONFIG_* parameters comparing to vanilla.
>
Oops sorry - some garbage get into.
Much less than 500 - cannot count precisely.
513 with garbage - cannot filter out correctly what is present in
vanilla kernel...
mvl21 patch againt vanilla _impressive_ by all means.
'diff -urN' output is more than 30MB.
Ihar Philips Filipau <[email protected]> :
[...]
> And those patches were not mine.
Testing/submitting/improving/syncing needs some generous amount of
time. You can easily help the author (especially) when things don't
evolve.
[...]
> [ I was playing only with network code - and I was concerned with
> performance more, than with image size. And had no luck achiving
> something. ]
Try harder :o)
[...]
> I have grepped thru 2.6.0-test0 - but I can find only entries in
> defconfigs - but no mentions in .h/.c files.
KConfig ?
[...]
> And yes - this option doesn't work in 'make menuconfig'.
No kernel tree at hand to figure what "doesn't work" mean but:
ed .config<<EOD
/# CONFIG_EMBEDDED is not set
d
wq
EOD
make oldconfig
works like a charm here.
If something seems wrong with 'make menuconfig', feel free to submit
a detailled PR here or through bugzilla.kernel.org (as long as it
isn't a networking thing).
[...]
> and more than 500 additional CONFIG_* parameters comparing to vanilla.
Provided the vendor can afford an army of kernel hackers to maintain
it, it is fine.
No need to Cc: me, I am subscribed to l-k.
--
Ueimor