* [Xenomai-core] Tiny Core Linux + xenomai/RTAI @ 2011-04-05 13:48 krishna m 2011-04-05 14:51 ` Robert Berger 2011-04-05 15:22 ` Gilles Chanteperdrix 0 siblings, 2 replies; 7+ messages in thread From: krishna m @ 2011-04-05 13:48 UTC (permalink / raw) To: xenomai, rtai [-- Attachment #1: Type: text/plain, Size: 194 bytes --] Has anyone tried applying Xenomai or RTAI patch to the tiny core Linux? Will it give a better performance compared to the plain vanilla Linux because the kernel footprint is small? [-- Attachment #2: Type: text/html, Size: 555 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-core] Tiny Core Linux + xenomai/RTAI 2011-04-05 13:48 [Xenomai-core] Tiny Core Linux + xenomai/RTAI krishna m @ 2011-04-05 14:51 ` Robert Berger 2011-04-05 17:17 ` Gilles Chanteperdrix 2011-04-05 15:22 ` Gilles Chanteperdrix 1 sibling, 1 reply; 7+ messages in thread From: Robert Berger @ 2011-04-05 14:51 UTC (permalink / raw) To: xenomai; +Cc: rtai Hi Krishna, On 04/05/2011 04:48 PM, krishna m wrote: > Has anyone tried applying Xenomai or RTAI patch to the tiny core Linux? No > Will it give a better performance compared to the plain vanilla Linux > because the kernel footprint is small? I guess the Linux Kernel is pretty much the same with the vanilla kernel. The reason it might offer better performance does most likely not come from the kernel, but because in such a small system less services are running, which might eat less CPU time. Will performance be better? Depends on what you mean with performance. If you apply Xenomai/RTAI to a vanilla Linux kernel throughput and number crunching (performance) will get worse and determinism will get better. Real-time is not about "performance" (speed, throughput), but about determinism and those are conflicting requirements. You can have a look at an article of mine for a more detailed explanation of what I mean: http://www.eetimes.com/design/embedded/4204740/Getting-real--time--about-embedded-GNU-Linux Regards, Robert > > > > _______________________________________________ > Rtai mailing list > Rtai@domain.hid > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai ...A clever person solves a problem.A wise person avoids it.- Einstein My public pgp key is available at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-core] Tiny Core Linux + xenomai/RTAI 2011-04-05 14:51 ` Robert Berger @ 2011-04-05 17:17 ` Gilles Chanteperdrix 2011-04-05 18:36 ` Robert Berger 0 siblings, 1 reply; 7+ messages in thread From: Gilles Chanteperdrix @ 2011-04-05 17:17 UTC (permalink / raw) To: gmane; +Cc: xenomai Robert Berger wrote: > Hi Krishna, > > On 04/05/2011 04:48 PM, krishna m wrote: >> Has anyone tried applying Xenomai or RTAI patch to the tiny core Linux? > > No > >> Will it give a better performance compared to the plain vanilla Linux >> because the kernel footprint is small? > > I guess the Linux Kernel is pretty much the same with the vanilla > kernel. The reason it might offer better performance does most likely > not come from the kernel, but because in such a small system less > services are running, which might eat less CPU time. > > Will performance be better? > > Depends on what you mean with performance. > > If you apply Xenomai/RTAI to a vanilla Linux kernel throughput and > number crunching (performance) will get worse and determinism will get > better. > > Real-time is not about "performance" (speed, throughput), but about > determinism and those are conflicting requirements. > > You can have a look at an article of mine for a more detailed > explanation of what I mean: > http://www.eetimes.com/design/embedded/4204740/Getting-real--time--about-embedded-GNU-Linux Ok, we are on Xenomai-core, so, let us discuss. If we admit that the OP is indeed talking about latencies (a quantifiable measure of determinism), suggesting that the effect on cache of the Linux kernel might influence the latencies is not completely irrelevant: the benchmark we make with Xenomai tend to consistently show that cache thrashing by the Linux kernel has an effect on latencies. Also, having shorter latencies means that we cover a larger range of user-application needs. So, we try to have short latencies. -- Gilles. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-core] Tiny Core Linux + xenomai/RTAI 2011-04-05 17:17 ` Gilles Chanteperdrix @ 2011-04-05 18:36 ` Robert Berger 2011-04-05 19:12 ` Gilles Chanteperdrix 0 siblings, 1 reply; 7+ messages in thread From: Robert Berger @ 2011-04-05 18:36 UTC (permalink / raw) To: xenomai Hi Gilles, On 04/05/2011 08:17 PM, Gilles Chanteperdrix wrote: > > Ok, we are on Xenomai-core, so, let us discuss. If we admit that the OP > is indeed talking about latencies (a quantifiable measure of > determinism), suggesting that the effect on cache of the Linux kernel > might influence the latencies is not completely irrelevant: the > benchmark we make with Xenomai tend to consistently show that cache > thrashing by the Linux kernel has an effect on latencies. Yes this did not immediately come into my mind. Linux cache thrashing affects latencies of threads running under Xenomai (user and/or kernel space), but as you point out ( http://permalink.gmane.org/gmane.linux.real-time.xenomai.devel/8167 ) that is distro independent. I know that the answer to this question might not be trivial, but what would you suggest could be done to minimize cache thrashing? > > Also, having shorter latencies means that we cover a larger range of > user-application needs. So, we try to have short latencies. > Whoever wants to see Xenomai latencies in action can compile cyclictest with and without Xenomai and see the differences. On the platforms I've tried so far the differences are clearly visible;) Regards, Robert ...Never test for an error condition you don't know how to handle. My public pgp key is available at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-core] Tiny Core Linux + xenomai/RTAI 2011-04-05 18:36 ` Robert Berger @ 2011-04-05 19:12 ` Gilles Chanteperdrix 2011-04-06 16:57 ` krishna m 0 siblings, 1 reply; 7+ messages in thread From: Gilles Chanteperdrix @ 2011-04-05 19:12 UTC (permalink / raw) To: gmane; +Cc: xenomai Robert Berger wrote: > Hi Gilles, > > On 04/05/2011 08:17 PM, Gilles Chanteperdrix wrote: >> Ok, we are on Xenomai-core, so, let us discuss. If we admit that the OP >> is indeed talking about latencies (a quantifiable measure of >> determinism), suggesting that the effect on cache of the Linux kernel >> might influence the latencies is not completely irrelevant: the >> benchmark we make with Xenomai tend to consistently show that cache >> thrashing by the Linux kernel has an effect on latencies. > > Yes this did not immediately come into my mind. Linux cache thrashing > affects latencies of threads running under Xenomai (user and/or kernel > space), but as you point out ( > http://permalink.gmane.org/gmane.linux.real-time.xenomai.devel/8167 ) > that is distro independent. Yes, and I completely agree with your answer, I was just replying for the sake of completeness. > > I know that the answer to this question might not be trivial, but what > would you suggest could be done to minimize cache thrashing? If we are talking embedded systems, you have control over the non real-time activities you run, you can try and be greedy in the way they use cache (I am not sure anyone really does that, I, for one, tried and optimize a toy application for cache usage to see that the effect is impressive). The other way, is not to minimize cache thrashing, but to minimize its effect on latencies. You can do that by increasing the frequency of the "critical" real-time task. By increasing its frequency, you make it more likely to remain in cache, and so decrease its latency. This is why, for instance, on most (*) platforms you get a better latency with smaller periods. On some embedded platforms, you also have the choice to lock some cache lines, or move some data or code to some fast memory essentially as fast as cache (TCMs or SRAMs on ARM). This is a promising solution, at least on ARM, where many SOCs have such special memory, but as far as I know, nobody tried yet and reported success of failure. (*) the exception being armv4 or armv5 without the FCSE extension, where the cache is flushed all the time anyway. > >> Also, having shorter latencies means that we cover a larger range of >> user-application needs. So, we try to have short latencies. >> > > Whoever wants to see Xenomai latencies in action can compile cyclictest > with and without Xenomai and see the differences. On the platforms I've > tried so far the differences are clearly visible;) Again, I agree with your answer, determinism, i.e. worst case latency is what matters for a real-time system, but: - smaller worst case latency covers a broader range of applications; - smaller average case latency means more CPU cycles for the Linux kernel to run, so, the dual-kernels based solutions still try to preserve the average case latency and are a bit special with regard to that particular question. -- Gilles. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-core] Tiny Core Linux + xenomai/RTAI 2011-04-05 19:12 ` Gilles Chanteperdrix @ 2011-04-06 16:57 ` krishna m 0 siblings, 0 replies; 7+ messages in thread From: krishna m @ 2011-04-06 16:57 UTC (permalink / raw) To: gilles.chanteperdrix, gmane; +Cc: xenomai ---------------------------------------- > Date: Tue, 5 Apr 2011 21:12:36 +0200 > From: gilles.chanteperdrix@xenomai.org > To: gmane@domain.hid > CC: xenomai@xenomai.org > Subject: Re: [Xenomai-core] Tiny Core Linux + xenomai/RTAI > > Robert Berger wrote: > > Hi Gilles, > > > > On 04/05/2011 08:17 PM, Gilles Chanteperdrix wrote: > >> Ok, we are on Xenomai-core, so, let us discuss. If we admit that the OP > >> is indeed talking about latencies (a quantifiable measure of > >> determinism), suggesting that the effect on cache of the Linux kernel > >> might influence the latencies is not completely irrelevant: the > >> benchmark we make with Xenomai tend to consistently show that cache > >> thrashing by the Linux kernel has an effect on latencies. > > > > Yes this did not immediately come into my mind. Linux cache thrashing > > affects latencies of threads running under Xenomai (user and/or kernel > > space), but as you point out ( > > http://permalink.gmane.org/gmane.linux.real-time.xenomai.devel/8167 ) > > that is distro independent. > > Yes, and I completely agree with your answer, I was just replying for > the sake of completeness. Thanks for replying. I got to read important points that affect the performance of a realtime system. I was indeed talking about the determinism of the RTOS when i referred to the performance. I am right now looking at interrupt determinism, task switch latency and jitter performance of the RTOS [Xenomai in this case]on x86 platform. Since there is no Cache locking mechanism on x86. i wanted to know if a smaller footprint kernel would improve the performance of the above mentioned parameters of RTOS. > > > > > I know that the answer to this question might not be trivial, but what > > would you suggest could be done to minimize cache thrashing? > > If we are talking embedded systems, you have control over the non > real-time activities you run, you can try and be greedy in the way they > use cache (I am not sure anyone really does that, I, for one, tried and > optimize a toy application for cache usage to see that the effect is > impressive). > > The other way, is not to minimize cache thrashing, but to minimize its > effect on latencies. You can do that by increasing the frequency of the > "critical" real-time task. By increasing its frequency, you make it more > likely to remain in cache, and so decrease its latency. This is why, for > instance, on most (*) platforms you get a better latency with smaller > periods. > > On some embedded platforms, you also have the choice to lock some cache > lines, or move some data or code to some fast memory essentially as fast > as cache (TCMs or SRAMs on ARM). This is a promising solution, at least > on ARM, where many SOCs have such special memory, but as far as I know, > nobody tried yet and reported success of failure. > > (*) the exception being armv4 or armv5 without the FCSE extension, where > the cache is flushed all the time anyway. > > > > >> Also, having shorter latencies means that we cover a larger range of > >> user-application needs. So, we try to have short latencies. > >> > > > > Whoever wants to see Xenomai latencies in action can compile cyclictest > > with and without Xenomai and see the differences. On the platforms I've > > tried so far the differences are clearly visible;) > > Again, I agree with your answer, determinism, i.e. worst case latency is > what matters for a real-time system, but: > - smaller worst case latency covers a broader range of applications; > - smaller average case latency means more CPU cycles for the Linux > kernel to run, so, the dual-kernels based solutions still try to > preserve the average case latency and are a bit special with regard to > that particular question. > > -- > Gilles. > > _______________________________________________ > Xenomai-core mailing list > Xenomai-core@domain.hid > https://mail.gna.org/listinfo/xenomai-core ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-core] Tiny Core Linux + xenomai/RTAI 2011-04-05 13:48 [Xenomai-core] Tiny Core Linux + xenomai/RTAI krishna m 2011-04-05 14:51 ` Robert Berger @ 2011-04-05 15:22 ` Gilles Chanteperdrix 1 sibling, 0 replies; 7+ messages in thread From: Gilles Chanteperdrix @ 2011-04-05 15:22 UTC (permalink / raw) To: krishna m; +Cc: xenomai krishna m wrote: > Has anyone tried applying Xenomai or RTAI patch to the tiny core > Linux? Will it give a better performance compared to the plain > vanilla Linux because the kernel footprint is small? Let us make this clear, since apparently people still seem to wonder: Xenomai only relies on the Linux kernel and the C library you use, it does not care about any distribution. Whether tiny core, Ubuntu, Fedora, Debian, Slackware, gentoo, it does not matter. And since you still have not understood either, a reminder: the Xenomai mailing lists are an old fashioned RFC 1855 plain text, 72 columns, bottom posting, mailing list. So, please no HTML, no multipart/alternative, no head-twisting long lines. And no cross-posting with RTAI mailing list, most people are not subscribed to the two lists, so will get mailer daemon errors when posting to the mailing list they are not subscribed to. -- Gilles. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-04-06 16:57 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-04-05 13:48 [Xenomai-core] Tiny Core Linux + xenomai/RTAI krishna m 2011-04-05 14:51 ` Robert Berger 2011-04-05 17:17 ` Gilles Chanteperdrix 2011-04-05 18:36 ` Robert Berger 2011-04-05 19:12 ` Gilles Chanteperdrix 2011-04-06 16:57 ` krishna m 2011-04-05 15:22 ` Gilles Chanteperdrix
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.