On Sun, 2005-11-06 at 15:01 +0100, Oliver Korpilla wrote: > I've mentioned timing exactness. Furthermore I don't think having context > switches when you can do without will do anything for performance. So my > terminology. I get shorter code paths, I get a minimal performance benefit, > I save a lot on memory copies, and my timing exactness / latency improves as > well. Yuo loose the comfortability of the user-space like a real C-library, stacks > 8k or 4k, lots of other libraries, no risk of freezing/oopsing the whole machine, etc.. > Since I do get benefits on all fronts, there is no mixup in terminology· As > long as the application can be held simple enough, an in-kernel approach > works. At least that is my conclusion. The "simple enough" probably rules out almost all real interesting applications. If you have a netfilter extension, that's completely another thing. > > > If there weren't performance and overhead differences > between a > > protected memory approach and doing it in > > > kernel space, why are nearly all realtime OS > > > without that distinction? *If* you have a core OS like typical RT-OS have, you *have* a sys-call-equivalent on every message since it is the only chance to save the memory manager from programmers faults. BTW does "realtime" not necessarily mean "fast". It means "deterministic in time" in the very first place. You can use RTAI or similar stuff. And with RTAI you can have Realtime-Tasks in Userspace (to put it simple). > > In my humble opinion this is because they're too simplistic. > > Being simple is an advantage if what you want is determinism. Optimizing for > short codepaths and minimal latency may seem simplistic, but all the > throughput optimizations found in Linux and the more complex coding make it > hard to use it in embedded realtime applications. You got it - the linux kernel is not for realtime and this will IMHO not change because if you want realtime on layer X you need realtime on layers below - with the overhead of guaranteeing the realtime behaviour over all the layers. And a realtime application is (and must be) designed on the whole for realtime behaviour (at least where it is necessary and specified) - which e.g. rules out 99% of all libraries. IMHO it boils down to either "fast on the average and/or long run" or "realtime". Or do you mean "realtime" as used now by marketing and sales droids as buzzword for "it's as fast as affordable"? Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
