Kernel 2.6 size increase - get_current()?
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 2 lines · Hollis Blanchard
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...
OT: Vanilla not for embedded?! Re: Kernel 2.6 size increase - get_current()?
Quoted 10 lines · Ihar Philips Filipau
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...
Re: OT: Vanilla not for embedded?! Re: Kernel 2.6 size increase - get_current()?
Where is the "deep" fork storaged, sounds interesting! At lets it should buisness friendly.
-a
Quoted 26 lines · Mike Fedyk
Quoted 10 lines · Ihar Philips Filipau
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/
Re: OT: Vanilla not for embedded?! Re: Kernel 2.6 size increase - get_current()?
In reply to Mike FedykQuoted 10 lines · Mike Fedyk
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.
Quoted 1 line
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?
Re: OT: Vanilla not for embedded?! Re: Kernel 2.6 size increase - get_current()?
Ihar Philips Filipau <[email protected]> :
[...]
Quoted 6 lines
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 ?
Quoted 2 lines
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.
[...]
Quoted 2 lines
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