Re: [Xenomai-core] [RFC][PATCH 4/4] shorten overrun loops of periodic timers

2006-08-18 Thread Jan Kiszka
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: I am thinking again about this patch: some handlers need to be rewritten, for example the posix timers handler, because the handler relies on the fact that

Re: [Xenomai-core] [rfc, patch] allow timer interrupt to be shared.

2006-08-18 Thread Philippe Gerum
On Thu, 2006-08-17 at 23:15 +0200, Gilles Chanteperdrix wrote: Hi, For review, you will find attached to this mail a patch which allows Xenomai to run on ARM platforms where the timer interrupt is shared. Such a platform have to define the constant IPIPE_HAVE_SHARED_TIMER_IRQ, as well as

Re: [Xenomai-core] Towards periodic mode over aperiodic timers

2006-08-18 Thread Philippe Gerum
On Thu, 2006-08-17 at 15:27 +0200, Jan Kiszka wrote: Hi, the conflict between skins preferring aperiodic timing vs. skin requiring periodic mode popped up once again on xenomai-help. One way out of this, likely THE way, is to map such tick-driven skins on a periodic timer over aperiodic

Re: [Xenomai-core] [rfc, patch] allow timer interrupt to be shared.

2006-08-18 Thread Gilles Chanteperdrix
Philippe Gerum wrote: I'd rather keep the number of obscure conditional macros as low as possible; we should actually try to reduce them since we have a growing number of real and pseudo-archs to support, and those macros tend to obfuscate the generic code. In the same vein, is there

[Xenomai-core] [PATCH] speed up building of posix apps

2006-08-18 Thread Jan Kiszka
Hi, with the growing number of wrapped posix applications also their fairly slow build process became visible. It somehow scaled badly. I had the idea to pass all wrapping commands to the linker via a file for quite some time. Now I tried it and it gives a nice speedup of roughly 400% for me

Re: [Xenomai-core] Towards periodic mode over aperiodic timers

2006-08-18 Thread Jan Kiszka
Philippe Gerum wrote: On Thu, 2006-08-17 at 15:27 +0200, Jan Kiszka wrote: Hi, the conflict between skins preferring aperiodic timing vs. skin requiring periodic mode popped up once again on xenomai-help. One way out of this, likely THE way, is to map such tick-driven skins on a periodic

Re: [Xenomai-core] [rfc, patch] allow timer interrupt to be shared.

2006-08-18 Thread Philippe Gerum
On Fri, 2006-08-18 at 13:16 +0200, Gilles Chanteperdrix wrote: Philippe Gerum wrote: I'd rather keep the number of obscure conditional macros as low as possible; we should actually try to reduce them since we have a growing number of real and pseudo-archs to support, and those macros

Re: [Xenomai-core] [PATCH] speed up building of posix apps

2006-08-18 Thread Philippe Gerum
On Fri, 2006-08-18 at 14:05 +0200, Jan Kiszka wrote: PS: What about the silence-libtool patch? I've heard neither ack nor nack so far. Still pondering the libtool --module issue. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org

Re: [Xenomai-core] [rfc, patch] allow timer interrupt to be shared.

2006-08-18 Thread Philippe Gerum
On Fri, 2006-08-18 at 14:36 +0200, Philippe Gerum wrote: On Fri, 2006-08-18 at 13:16 +0200, Gilles Chanteperdrix wrote: Philippe Gerum wrote: I'd rather keep the number of obscure conditional macros as low as possible; we should actually try to reduce them since we have a growing

Re: [Xenomai-core] [PATCH] speed up building of posix apps

2006-08-18 Thread Jan Kiszka
Philippe Gerum wrote: On Fri, 2006-08-18 at 14:05 +0200, Jan Kiszka wrote: PS: What about the silence-libtool patch? I've heard neither ack nor nack so far. Still pondering the libtool --module issue. Try a grep -r shouldnotlink `find /usr/lib/ -name *.la` to get an impression what kind

Making skin libraries not dlopenable (was: Re: [Xenomai-core] [PATCH] silence libtool warnings)

2006-08-18 Thread Philippe Gerum
On Fri, 2006-08-11 at 18:09 +0200, Jan Kiszka wrote: As we should not statically link the native/rtdm libraries against our new CAN tools (that code may reside on small embedded devices soon...), the old Linking the executable ... is not portable! warning now pops up again during Xenomai

Re: [Xenomai-core] [PATCH] speed up building of posix apps

2006-08-18 Thread Gilles Chanteperdrix
Jan Kiszka wrote: Hi, with the growing number of wrapped posix applications also their fairly slow build process became visible. It somehow scaled badly. I had the idea to pass all wrapping commands to the linker via a file for quite some time. Now I tried it and it gives a nice

[Xenomai-core] Re: [PATCH] fix 2.4 build of mksound workaround

2006-08-18 Thread Philippe Gerum
On Mon, 2006-08-14 at 18:57 +0200, Jan Kiszka wrote: Hi Philippe, various issues with the new mksound workaround for x86-2.4 kernels popped up here during test builds (wrong dependency on CONFIG_XENO_HW_NMI_DEBUG_LATENCY, missing dep on CONFIG_VT, missing linux/vt_kern.h). The attached

Re: [Xenomai-core] Towards periodic mode over aperiodic timers

2006-08-18 Thread Philippe Gerum
On Fri, 2006-08-18 at 16:41 +0200, Gilles Chanteperdrix wrote: Philippe Gerum wrote: Before we start implementing anything, there is still another issue (at least) to address: how do we deal with the wall clock time, basically xnpod_get_time/set_time, and the xnarch-level counterparts,

Re: [Xenomai-core] [PATCH] speed up building of posix apps

2006-08-18 Thread Jan Kiszka
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi, with the growing number of wrapped posix applications also their fairly slow build process became visible. It somehow scaled badly. I had the idea to pass all wrapping commands to the linker via a file for quite some time.

Re: [Xenomai-core] ksrc/driver refactoring

2006-08-18 Thread Philippe Gerum
On Wed, 2006-08-16 at 16:14 +0200, Klaas Gadeyne wrote: I just wanted to drop a note that I did some refactoring on the drivers directory (16550A-serial) and the config menus. If anything is broken, shoot me. I don't think this is related, but 2 students of mine got stuck on a linker

[Xenomai-core] Re: Test, benchmark

2006-08-18 Thread Jim Cromie
Jan Kiszka wrote: Hi all, Jim raised these issues nicely to a generic level. I would like to pick it up and add some thoughts. Jim Cromie wrote: ... FWIW, I noted that xeno-test is not running these: - switchbench - switchtest - irqbench Im not sure they belong in xeno-test though, since

[Xenomai-core] enable-linux-build option documentation.

2006-08-18 Thread Gilles Chanteperdrix
Hi, Some time ago, I sent a patch adding documentation for the --enable-linux-build option to README.INSTALL [1], is there anyone opposed to this modification ? Or may I commit it ? [1] https://mail.gna.org/public/xenomai-core/2006-07/msg00059.html --

Re: [Xenomai-core] [PATCH] speed up building of posix apps

2006-08-18 Thread Gilles Chanteperdrix
Jan Kiszka wrote: Ok, here comes version 2, now with detection of the required ld feature. Falls back to normal behaviour if ld is too old. Could you test it please? [Grmbl, the fun stops where autoconf begins...] Seems to work. But maybe we could find the bottleneck and fix it in a

Re: [Xenomai-core] [PATCH] speed up building of posix apps

2006-08-18 Thread Jan Kiszka
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Ok, here comes version 2, now with detection of the required ld feature. Falls back to normal behaviour if ld is too old. Could you test it please? [Grmbl, the fun stops where autoconf begins...] Seems to work. But maybe we could find

Re: [Xenomai-core] Re: Test, benchmark

2006-08-18 Thread Gilles Chanteperdrix
Gilles Chanteperdrix wrote: A question: I see that you always use the -n option, do you have problems running the test without this option ? When launched with the -n option switchtest does not test cpu context switches. s/cpu/FPU/ -- Gilles

[Xenomai-core] Re: Test, benchmark

2006-08-18 Thread Jan Kiszka
Jim Cromie wrote: ... just responding to small part now.. this patch adds switchtest, switchbench (and drops switch) and irqbench. each test-prog has a corresponding $XENOT_progname with which you can inject new test arguments individually. Most of these can be undef'd, except for

Re: [Xenomai-core] Re: Test, benchmark

2006-08-18 Thread Jim Cromie
Gilles Chanteperdrix wrote: Jim Cromie wrote: [ 1574.162754] Xenomai: starting RTDM services. cpu 0: 2079 context switches. cpu 0: 4212 context switches. cpu 0: 6336 context switches. cpu 0: 8442 context switches. ... cpu 0: 246981 context switches. cpu 0: 249096 context

Re: [Xenomai-core] Re: Test, benchmark

2006-08-18 Thread Jan Kiszka
Jim Cromie wrote: ... Also, 2 possible output change requests: a - print per-sample measures, not accumulating ones. this is more consistent with latency, which prints the latencies seen over the 1-sec sample period This also feeds better into histogram, w/o adding 'delta' logic

[Xenomai-core] Re: Test, benchmark

2006-08-18 Thread Jim Cromie
Jan Kiszka wrote: Jim Cromie wrote: ... just responding to small part now.. this patch adds switchtest, switchbench (and drops switch) and irqbench. each test-prog has a corresponding $XENOT_progname with which you can inject new test arguments individually. Most of these can be undef'd,

[Xenomai-core] Handling of null delay in asm/hal.h

2006-08-18 Thread Gilles Chanteperdrix
Hi, at some point in time, we decided to trigger directly the timer irq when called on x86 to program a null delay. Attached a patch which does the same for all other architectures. -- Gilles Chanteperdrix. Index: include/asm-arm/hal.h

Re: [Xenomai-core] [PATCH] speed up building of posix apps

2006-08-18 Thread Gilles Chanteperdrix
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Ok, here comes version 2, now with detection of the required ld feature. Falls back to normal behaviour if ld is too old. Could you test it please? [Grmbl, the fun stops where autoconf begins...]

Re: [Xenomai-core] Re: Test, benchmark

2006-08-18 Thread Gilles Chanteperdrix
Jim Cromie wrote: I think I added it at some point when I wasnt getting output. It works without the -n too, which should be added via XENOT_SWITCHTEST, not stuffed in by default. You could just edit it out of patch, if otherwize satisfied... Patch applied without -n, thanks. --