Re: [Xenomai-core] irq0 usage
> Ok, so we will agree that the 20%/60% ratios can't be compared, in > fact. Do you mean that this is not a fair comparison or that I should not be this slow compared to RTAI? > The fact that the GX still has to use a crappy 8253 PIT for timing and > must emulate the TSC using one of the PIT channels is not helping at > all. Emulating the TSC costs 1 x time_of(outb) + 2 x time_of(inb), > each > time a timestamp is read via the rdtsc emulation code. That is costly. Do you agree that if I build with TSC on and disable suspend on halt (or use idle=poll) that xenomai will use rdtsc? > It switches to supervisor mode using an interrupt (0x80); that logic > is > really costly compared to the SEP entry. I'd say ~800ns-1us vs 200ns > on > average for your target. This is bad, but since our fastest userspace period is 500us it is not a dealbreaker. Just rt_task_wait_next_period() and one mutex lock/ unlock is too much for it. > Btw, did you fix your driver code regarding the unprotected usage of > FPU > in pure Linux kernel context? Yes in fact the new driver does not use floats at all. It's purely integer math. > Eh, no. TSC is always preferred when available. I was looking at rthal_timer_program_shot(). > Frankly, those figures are really surprising. rdtsc() is about > 100-200ns, running rthal_get_8254_tsc() is a lot, lot more. I asked above if what we did would really use the TSC or not. What do you think? > No, when _your_ test runs. So we should run latency -p and then our test and look at the output? Thanks, Steven ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] irq0 usage
On Mon, 2009-03-23 at 19:03 -0400, Steven Seeger wrote: > > What are you comparing, I mean, exactly? > > All kernel RTAI vs all userland Xenomai? > > Yes. > Ok, so we will agree that the 20%/60% ratios can't be compared, in fact. > > > > > > The timer handler is charged for the callbacks it runs, so it really > > boils down to what code is attached to Xenomai timers, aside of the > > built-in scheduler tick. > > In this case we have only a single RTDM timer that fires ever 125 us > and does nothing (as a test.) It will be easy to remove this and > compare the amount of usage irq0 handler uses without it. I know it'll > be at least 14 or 15. Let's check this anyway. The fact that the GX still has to use a crappy 8253 PIT for timing and must emulate the TSC using one of the PIT channels is not helping at all. Emulating the TSC costs 1 x time_of(outb) + 2 x time_of(inb), each time a timestamp is read via the rdtsc emulation code. That is costly. > > > > > > > When you measure that load, what does /proc/xenomai/timerstat say? > > > >> I know > >> there is some overhead with userspace calls but hte irq0 handler > >> alone > >> accounts for 20% of it. Are there any options that can speed things > >> up? > >> > > > > Yeah, but you won't like it: buy a Geode that has SEP support for > > syscalls and a working TSC, then switch on --enable-x86-sep. Ok, > > granted, that is _not_ funny. > > We have a new Geode that has SEP and yes, things are faster. Just how > much overhead does syscall create? It switches to supervisor mode using an interrupt (0x80); that logic is really costly compared to the SEP entry. I'd say ~800ns-1us vs 200ns on average for your target. > Is there no better option other > than SEP? If we could have kernel threads work without corrupting > userland FPU contexts then we could use our two higher priority > drivers in a kernel module to save overhead. Btw, did you fix your driver code regarding the unprotected usage of FPU in pure Linux kernel context? > > Is TSC really going to make that much of a difference? It seems that > xenomai uses PIT anyway. Eh, no. TSC is always preferred when available. > We can build with TSC if we disable suspend > on halt and it works. If we do this the usage stays the same. It may > drop a couple tenths of a percent. Frankly, those figures are really surprising. rdtsc() is about 100-200ns, running rthal_get_8254_tsc() is a lot, lot more. > > > What would be interesting is to get the value reported for the timer > > interrupt when the standard latency test runs at the same frequency > > than > > your application does (use -p option). > > So you mean look at cat /proc/stat/xenomai while running latency test - > p? > No, when _your_ test runs. > Steven > -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] irq0 usage
> What are you comparing, I mean, exactly? > All kernel RTAI vs all userland Xenomai? Yes. > > > The timer handler is charged for the callbacks it runs, so it really > boils down to what code is attached to Xenomai timers, aside of the > built-in scheduler tick. In this case we have only a single RTDM timer that fires ever 125 us and does nothing (as a test.) It will be easy to remove this and compare the amount of usage irq0 handler uses without it. I know it'll be at least 14 or 15. > > > When you measure that load, what does /proc/xenomai/timerstat say? > >> I know >> there is some overhead with userspace calls but hte irq0 handler >> alone >> accounts for 20% of it. Are there any options that can speed things >> up? >> > > Yeah, but you won't like it: buy a Geode that has SEP support for > syscalls and a working TSC, then switch on --enable-x86-sep. Ok, > granted, that is _not_ funny. We have a new Geode that has SEP and yes, things are faster. Just how much overhead does syscall create? Is there no better option other than SEP? If we could have kernel threads work without corrupting userland FPU contexts then we could use our two higher priority drivers in a kernel module to save overhead. Is TSC really going to make that much of a difference? It seems that xenomai uses PIT anyway. We can build with TSC if we disable suspend on halt and it works. If we do this the usage stays the same. It may drop a couple tenths of a percent. > What would be interesting is to get the value reported for the timer > interrupt when the standard latency test runs at the same frequency > than > your application does (use -p option). So you mean look at cat /proc/stat/xenomai while running latency test - p? Steven ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] irq0 usage
On Mon, 2009-03-23 at 15:59 -0400, Steven Seeger wrote: > We are still running into issues where irq0 is using a lot of CPU > time. The same threads on an RTAi system on the same hardware used > about 13% of the CPU but are using closer to 60% on Xenomai. What are you comparing, I mean, exactly? All kernel RTAI vs all userland Xenomai? The timer handler is charged for the callbacks it runs, so it really boils down to what code is attached to Xenomai timers, aside of the built-in scheduler tick. When you measure that load, what does /proc/xenomai/timerstat say? > I know > there is some overhead with userspace calls but hte irq0 handler alone > accounts for 20% of it. Are there any options that can speed things up? > Yeah, but you won't like it: buy a Geode that has SEP support for syscalls and a working TSC, then switch on --enable-x86-sep. Ok, granted, that is _not_ funny. What would be interesting is to get the value reported for the timer interrupt when the standard latency test runs at the same frequency than your application does (use -p option). > We've tried both one shot and periodic modes. I confirmed that the ISA > i/o timing is 1.3usec per outb as expected. > > Steven > > > ___ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai
Hi, 1/ Please check the "support frame" on www.xenomai.org and use the proper mailing list: xenomai-help is the one you need to post to for this kind of questions at first. It is totally suitable for configuration or compilation issues. 2/ Adeos patch is not relevant in the case of the simulator. You can build/use the simulator regardless of your target configuration. 3/ To answer your question now: Tix-4.1 is the problem here (API problem with tixDirList:ListHierarchy). An easy way to build and make the simulator work is to switch to an older distribution. Debian/Sarge is known to work for instance. A good approach here is to use a qemu or a virtualbox that runs on top of your host platform. If you benefit from a robust hardware machine (at least Dual core or Core 2 Duo), you'll be able to have the simulator run with a very low overhead. --Bruno 2009/3/23 Vandana Sasidharan > > Hi > > I am getting an error when I am trying to "MAKE" Xenosim- 2.4.7. > I have already installed Xenomai- 2.4.7 along with libelf -0.8.10 , Tcl > 8.3.5, Tk 8.3.5 , Tix 4.1.0.007 and an adeos patch that is adeos-ipipe > -2.6.25-x86-2.0-08.patch on a linux kernel which we built which has a > version Linux 2.6.25.11. > after configuring Xenosim along with the gcc -2.95.3 tar .gz when I try to > "make" the xenosim I'm getting an error : > > xenomai-2.4.7/xenosim-2.4.7/adapter/adapter.cc: 65: error :too few > arguments > xenomai-2.4.7/xenosim-2.4.7/adapter/adapter.cc: 67: error :too few > arguments > > Can anyone tell me why am I getting this error and how to get rid of this? > > > =-=-= > Notice: The information contained in this e-mail > message and/or attachments to it may contain > confidential or privileged information. If you are > not the intended recipient, any dissemination, use, > review, distribution, printing or copying of the > information contained in this e-mail message > and/or attachments to it are strictly prohibited. If > you have received this communication in error, > please notify us by reply e-mail or telephone and > immediately and permanently delete the message > and any attachments. Thank you > > > > > ___ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core > > ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] irq0 usage
We are still running into issues where irq0 is using a lot of CPU time. The same threads on an RTAi system on the same hardware used about 13% of the CPU but are using closer to 60% on Xenomai. I know there is some overhead with userspace calls but hte irq0 handler alone accounts for 20% of it. Are there any options that can speed things up? We've tried both one shot and periodic modes. I confirmed that the ISA i/o timing is 1.3usec per outb as expected. Steven ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Xenomai
Hi I am getting an error when I am trying to "MAKE" Xenosim- 2.4.7. I have already installed Xenomai- 2.4.7 along with libelf -0.8.10 , Tcl 8.3.5, Tk 8.3.5 , Tix 4.1.0.007 and an adeos patch that is adeos-ipipe -2.6.25-x86-2.0-08.patch on a linux kernel which we built which has a version Linux 2.6.25.11. after configuring Xenosim along with the gcc -2.95.3 tar .gz when I try to "make" the xenosim I'm getting an error : xenomai-2.4.7/xenosim-2.4.7/adapter/adapter.cc: 65: error :too few arguments xenomai-2.4.7/xenosim-2.4.7/adapter/adapter.cc: 67: error :too few arguments Can anyone tell me why am I getting this error and how to get rid of this? =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
