Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
decision (we could store the first pending thread priority in a
user/kernel shared area, with the complication that we would need
updating this priority if it ever changes, but to get the priority of
the current thread
(+), 4 deletions(-)
Index: b/ChangeLog
===
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2008-08-22 Jan Kiszka [EMAIL PROTECTED]
+
+ * configure.in: Enable SMP support by default.
+
2008-08-21 Philippe Gerum [EMAIL
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Disabling SMP (on platforms where this isn't off by design already) is
an optimization. In contrast, not enabling it by default is doomed to
cause problems for users that run ./configure without looking into each
and every switch - now
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Disabling SMP (on platforms where this isn't off by design already) is
an optimization. In contrast, not enabling it by default is doomed to
cause problems for users that run ./configure without
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Disabling SMP (on platforms where this isn't off by design already) is
an optimization. In contrast, not enabling it by default is doomed to
cause
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Disabling SMP (on platforms where this isn't off by design already) is
an optimization. In contrast
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Disabling SMP (on platforms where this isn't off by design
As the subject says. Passed your unit_mutex test, nothing else tried
yet, weekend is calling.
---
configure.in|1 +
include/asm-x86/atomic_64.h | 31 +--
ksrc/arch/x86/Kconfig |2 +-
3 files changed, 31 insertions(+), 3 deletions(-)
Hi Gilles,
do you - or anyone else - happen to have some patches under preparation
to extend also the native skin with the newly added CONFIG_XENO_FASTSEM
support? Just to avoid duplicate work (we are about to work on this).
Jan
signature.asc
Description: OpenPGP digital signature
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
bad news, everyone :(. According to the result of some lengthy debug
session with a customer and several ad-hoc lttng
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
+/* We are awake, no one must steal our lock anymore. */
+thread-wwake = NULL;
+
This is wrong, whether or not no one must steal our lock anymore will be
decided at the redo label, when we test and set, the synch owner.
Maybe I
For unknown (historical?) reasons, there are 3 identical implementations
of add_proc_leaf services in Xenomai right now. This patch switches them
all to the rthal provided version.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
include/asm-generic/hal.h | 10 +++
ksrc/arch/generic/hal.c
=0
to address the deficit.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
ksrc/nucleus/registry.c | 41 +
1 file changed, 41 insertions(+)
Index: b/ksrc/nucleus/registry.c
===
--- a/ksrc
Hi,
bad news, everyone :(. According to the result of some lengthy debug
session with a customer and several ad-hoc lttng instrumentations, we
have a fatal bug in the nucleus' implementation of the lock stealing
algorithm. Consider this scenario:
1. Thread A acquires Mutex X successfully, ie. it
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
bad news, everyone :(. According to the result of some lengthy debug
session with a customer and several ad-hoc lttng instrumentations, we
have a fatal bug in the nucleus' implementation of the lock stealing
algorithm. Consider this scenario:
1
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
- head = snprintf(name, XNOBJECT_NAME_LEN, IRQ%d: , irq);
- name += head;
- strncpy(name, intr-name, XNOBJECT_NAME_LEN-head);
+ head = snprintf(name_buf, XNOBJECT_NAME_LEN, IRQ%d: , irq);
+ strncpy(name_buf + head, intr-name,
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
bad news, everyone :(. According to the result of some lengthy debug
session with a customer and several ad-hoc lttng instrumentations, we
have a fatal bug in the nucleus' implementation of the lock
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
bad news, everyone :(. According to the result of some lengthy debug
session with a customer and several ad-hoc lttng instrumentations, we
have a fatal bug
Current lock stealing implementation encodes the new owner woken up,
but not yet scheduled state redundantly. First, the XNWAKEN thread bit
is set and, second, the wwake field in xnthread_t points to the
xnsynch_t object that the thread is about to own.
Apparently, no technical benefit can be
Philippe Gerum wrote:
...
This would be even better with a proper iterator construct.
Something like this? I think I tested most cases successfully (e.g. 4
CPUs with a shared IRQ), but the code should also be better readable,
thus better reviewable. Comments/feedback welcome.
Jan
---
Jan Kiszka wrote:
Petr Cervenka wrote:
I ran a test during last weekend (and nothing wrong happened). But the
/proc/xenomai/stat output is strange. Probably some type cast error, because
18446744071739514846 = 0x8A939FDE and the appropriate value perhaps
should
Wolfgang Grandegger wrote:
Hi Jan,
Jan Kiszka wrote:
Due to a global definition of 'clock' in latest 2.6.26, we now have a
problem with two rtcan drivers. Below is a fix that breaks those
drivers' user interface by rename the conflicting variable which
unfortunately also renames the module
Benjamin ZORES wrote:
Hi,
I've encountered a little problem when trying to propagate an ISR from
Xenomai to Linux context.
To sum up clearly, I'm writing an RT kernel module that drives a PCI card.
I've registered a nucleus ISR handler on the IRQ attributed to this card.
On some
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
include/native/mutex.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
Index: b/include/native/mutex.h
===
--- a/include/native/mutex.h
+++ b/include/native/mutex.h
.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
include/native/mutex.h|3 +++
ksrc/skins/native/mutex.c |5 +
2 files changed, 8 insertions(+)
Index: b/include/native/mutex.h
===
--- a/include/native/mutex.h
+++ b
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
This can be helpful for debugging the (futile) release attempts of
mutexes by tasks that do not own them.
Returning the RT_TASK reference may appear more consistent on first
sight, but it cannot be guaranteed that the owner is actually a native
Alexis Berlemont wrote:
Hi,
Sorry for answering so lately, I was not at home the last four days.
Required with 2.6.26 where there is no more calc64. And asm/div64.h is
what you actually want.
Thanks.
Sorry, but the committed fix is bogus for 2.6.26. I would suggest just
to pick up what
Hi,
finally I found a few minutes to port forward our old kgdb patch series,
once developed for a customer on 2.6.24, to latest 2.6.26-rcX.
As you may have heard, 2.6.26 will include a cleaned up and stripped
down kgdb, so far supporting x86 only, but on the way to finally
establish a patch-free
[EMAIL PROTECTED] wrote:
Hi,
Sorry, but the committed fix is bogus for 2.6.26. I would suggest just
to pick up what I proposed, kernel headers do the same since ages
(including 2.4).
Argh... I am an [CENSORED].
I missed everything, I was in another dimension. I had a too quick look at
Required with 2.6.26 where there is no more calc64. And asm/div64.h is
what you actually want.
Jan
PS: Kernel-style reformatting would be nice - one day... :-
Index: ksrc/drivers/comedi/instruction.c
===
---
Due to a global definition of 'clock' in latest 2.6.26, we now have a
problem with two rtcan drivers. Below is a fix that breaks those
drivers' user interface by rename the conflicting variable which
unfortunately also renames the module parameter name.
An alternative approach would be to add a
Philippe Gerum wrote:
Author: rpm
Date: Sat Jun 28 18:23:51 2008
New Revision: 3998
URL: http://svn.gna.org/viewcvs/xenomai?rev=3998view=rev
Log:
Merge COMEDI over RTDM framework
Added:
...
trunk/ksrc/skins/comedi/
trunk/ksrc/skins/comedi/Config.h
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Hi Jan,
when compiling xenomai v2.4.x for ARM with gcc 4.2.1, I get plenty
of
warnings like:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Since binding of the semaphore heaps is now made by xeno_skin_bind,
there is
much less modifications in src/skins/posix/init.c. However, I had to do
something really ugly: since binding the semaphore
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Since binding of the semaphore heaps is now made by xeno_skin_bind,
there is
much less modifications in src/skins/posix/init.c. However, I had
The lazy xnfree mechanism turned out to be too lazy: Just run some
testsuite program and what /proc/xenomai/heap - it will not reach the
level it has on freshly booted box.
The reason is that TCBs of threads that are released over the ROOT
thread will only get purged after the next
Gilles Chanteperdrix wrote:
On Tue, May 13, 2008 at 10:26 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
@@ -1236,6 +1236,9 @@ void xnpod_delete_thread(xnthread_t *thr
xnthread_cleanup_tcb(thread);
xnarch_finalize_no_switch(xnthread_archtcb(thread
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
On Tue, May 13, 2008 at 11:10 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Tue, May 13, 2008 at 10:26 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
@@ -1236,6 +1236,9 @@ void xnpod_delete_thread(xnthread_t *thr
Gilles Chanteperdrix wrote:
On Tue, May 13, 2008 at 11:32 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
On Tue, May 13, 2008 at 11:10 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Tue, May 13, 2008 at 10:26 AM
This has been posted earlier already: Fix deadlocks when debugging
Xenomai applications via gdb by removing any attempt to acquire
sighand_lock (while holding rq_lock). This patch also cleans up the now
unused lock wrapper.
Unless someone complains, I'm going to merge this later today into trunk
I expressed my skepticism about this global timer freeze before :-, and
now it hit me unpleasantly (Customer: Is it normal that Xenomai stops
working after the gdb session? Jan [scratching head]: Hmm, no...).
After more scratching I think I found the reason: The target decided to
die after some
Gilles Chanteperdrix wrote:
On Fri, May 9, 2008 at 11:29 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
+ if (xnthread_test_info(thread, XNDEBUG))
+ unlock_timers();
+
Will this work if several threads are currently being debugged ?
Not better or worse than with the current
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
On Fri, May 9, 2008 at 11:29 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
+ if (xnthread_test_info(thread, XNDEBUG))
+ unlock_timers();
+
Will this work if several threads are currently being debugged ?
Not better or worse than
Philippe Gerum wrote:
Jan Kiszka wrote:
This has been posted earlier already: Fix deadlocks when debugging
Xenomai applications via gdb by removing any attempt to acquire
sighand_lock (while holding rq_lock). This patch also cleans up the now
unused lock wrapper.
Unless someone complains
Hi,
after hacking away the barriers I-pipe erected in front of lockdep
(patches will follow on adeos-main), I was finally able to visualize a
bit more what our colleagues see in reality on SMP: some ugly, not yet
understood circular dependency when running some Xenomai app under gdb.
What lockdep
Jan Kiszka wrote:
Hi,
after hacking away the barriers I-pipe erected in front of lockdep
(patches will follow on adeos-main), I was finally able to visualize a
bit more what our colleagues see in reality on SMP: some ugly, not yet
understood circular dependency when running some Xenomai app
Hi,
not worth to call it a patch, at least not when looking at the second
file.
Lockdep gets unhappy when I-pipe is enabled because
a) TRACE_IRQS_ON/OFF instrumentations in entry_64.S do not correlate
with the root's pipeline state. Instead of fixing the latter (which
costs extra
Gilles Chanteperdrix wrote:
On Mon, May 5, 2008 at 6:08 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
do_schedule_event() is the culprit when it reads the pending signals on the
shared queue (XNDEBUG check for rearming the timers),
A stupid suggestion: if we know that the spinlock is always
Philippe Gerum wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
On Mon, May 5, 2008 at 6:08 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
do_schedule_event() is the culprit when it reads the pending signals on
the
shared queue (XNDEBUG check for rearming the timers),
A stupid
Hi,
trunk check-in #3369 did not just remove some questionable critical
sections, it also happen to fix two ugly bugs in the POSIX skin: The
user was not able to pass NULL attributes down to mutex_init and
cond_init. Find a backport of that patch for 2.4.x attached.
Jan
--
Siemens AG,
Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 2:59 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Hi,
trunk check-in #3369 did not just remove some questionable critical
sections, it also happen to fix two ugly bugs in the POSIX skin: The
user was not able to pass NULL attributes down
Gilles Chanteperdrix wrote:
Hi,
the patch series to come for review adds support for user-space mutexes to the
posix skin. Since I wanted this support to be available on my AT91RM9200, the
patch series start with patches which are mainly for the ARM architecture, to
end with
===
--- xenomai/ChangeLog (Revision 3698)
+++ xenomai/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2008-04-11 Jan Kiszka [EMAIL PROTECTED]
+
+ * src/skins/native/task.c: Fix tiny memory leaks of the task's
+ self-reference key.
+
2008-04-10 Philippe Gerum [EMAIL PROTECTED]
* src
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Nothing critical, but when using rt_task_self != NULL as a hint if the
caller is Xenomai-mapped or not, this stall malloc can become at least
unpleasant. This is also material for stable.
This looks useless: TSD cleanup routines
Tomas Kalibera wrote:
Hi,
I've tried a more defensive kernel setup your patch (no.6). The lockup
is still there. It happens after a realtime task is started, though I
was unable to track exactly when - it does not crash in a debugger,
does not crash with strace, breaks SysRq, and printing
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
This patch may do the trick: it uses the inverted tsc-to-ns function
instead of the frequency-based one. Be warned, it is totally
untested inside Xenomai, I just ran it in a user space test program
Gilles Chanteperdrix wrote:
On Fri, Apr 4, 2008 at 12:45 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
This patch may do the trick: it uses the inverted tsc-to-ns function
instead of the frequency-based one
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
On Fri, Apr 4, 2008 at 12:45 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
This patch may do the trick: it uses the inverted tsc-to-ns function
instead
Gilles Chanteperdrix wrote:
Right. We are approximating a fraction with another fraction. But my
first impression remains: I do not like the idea of making
xnarch_ns_to_tsc wrong because xnarch_tsc_to_ns is wrong.
Well, my first impression was originally the same: If we still need
llimd in
Sebastian Smolorz wrote:
Gilles Chanteperdrix wrote:
On Wed, Apr 2, 2008 at 5:58 PM, Sebastian Smolorz
[EMAIL PROTECTED] wrote:
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Cornelius Köpp wrote:
I talked with Sebastian Smolorz about this and he builds his own
Gilles Chanteperdrix wrote:
On Thu, Apr 3, 2008 at 2:17 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Sebastian Smolorz wrote:
Gilles Chanteperdrix wrote:
On Wed, Apr 2, 2008 at 5:58 PM, Sebastian Smolorz
[EMAIL PROTECTED] wrote:
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Cornelius Köpp wrote:
Hello,
I run the latency test from testsuite on several hard and software
configurations. Running on Xenomai 2.4.2, Linux 2.6.24 the results
shows a strange behavior: In Kernel mode (-t1) the latencys
constantly linear
/include/rtdm/rtdm_driver.h
@@ -4,6 +4,7 @@
*
* @note Copyright (C) 2005-2007 Jan Kiszka [EMAIL PROTECTED]
* @note Copyright (C) 2005 Joerg Langenberg [EMAIL PROTECTED]
+ * @note Copyright (C) 2008 Gilles Chanteperdrix [EMAIL PROTECTED]
*
* Xenomai is free software; you can redistribute
Philippe,
I noticed that you merged patch 1-4. What are the plans for (or concerns
about) the ticket xnlock and the UP debugging changes?
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
Maybe someone with idle cycles left could have a look at this.
Jan
---BeginMessage---
Package: xenomai-runtime
Severity: important
Version: 2.4.2-2
User: [EMAIL PROTECTED]
Usertags: goal-dash
Hello maintainer,
While performing an archive wide checkbashisms (from the 'devscripts' package)
Hi,
doesn't this patch [1] have some relevance for us as well? As we use
xnarch_remap_io_page_range also for non-IO memory, I'm hesitating to
suggest that we apply this unconditionally at xnarch level. Ideas welcome.
Jan
[1] http://permalink.gmane.org/gmane.linux.kernel/653921
signature.asc
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
doesn't this patch [1] have some relevance for us as well? As we use
xnarch_remap_io_page_range also for non-IO memory, I'm hesitating to
suggest that we apply this unconditionally at xnarch level. Ideas welcome.
Yes, I think it makes a lot
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
doesn't this patch [1] have some relevance for us as well? As we use
xnarch_remap_io_page_range also for non-IO memory, I'm hesitating to
suggest that we apply this unconditionally at xnarch level. Ideas
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
doesn't this patch [1] have some relevance for us as well? As we use
xnarch_remap_io_page_range also for non-IO memory, I'm
Hi,
here comes version 2 of my xnlock rework. Changes since the first
release:
- Moved xnlock_spin out-of-line instead uninlining the irqsave/restore
services
- Beautified xnlock_dbg interface (now only static-inlines)
- Split-up basic xnlock_dbg refactoring from whitespace fixes
The owner check on xnlock release looks light-weight in first sight, but
it isn't. It requires a processor-id lookup + it adds a conditional to
the otherwise unconditional release path. Moreover, this code is inlined
into every xnlock_put user, thus increases the text size of hot paths.
This
After all the refactoring, arming xnlock_dbg services also for
!CONFIG_SMP setups was straightforward.
---
include/asm-generic/bits/pod.h |4 ++--
include/asm-generic/system.h | 31 +++
ksrc/nucleus/intr.c|4 ++--
ksrc/nucleus/module.c
No functional changes.
---
include/asm-generic/system.h | 145 +--
1 file changed, 73 insertions(+), 72 deletions(-)
Index: b/include/asm-generic/system.h
===
---
Concentrate all xnlock debugging related code in static inline wrappers
that can easily be switched on and off without visual harm for the lock
services themselves. This does not yet change the debugging logic, it
just saves a few byte text by avoiding redundant processor-id accesses.
---
The origin of this series: When Nick Piggin posted his first suggestion
for ticket spinlocks on LKML, I immediately liked the idea. For details
check LWN [1], in a nutshell: This algorithm enforces strict FIFO order
for the admission to contended spinlocks, thus it improves the
determinism on SMP
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi,
here comes version 2 of my xnlock rework. Changes since the first
release:
- Moved xnlock_spin out-of-line instead uninlining the irqsave/restore
services
The size changes are not as dramatic as with the first version
===
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2008-03-01 Jan Kiszka [EMAIL PROTECTED]
+
+ * include/asm-generic/system.h (xnlock_put): Add proper barrier.
+
2008-02-15 Gilles Chanteperdrix [EMAIL PROTECTED]
* src/skins/posix
[My favorite again... :-]
The initial rpi_push in xnshadow_start takes place for the caller's CPU,
instead of the thread's target CPU.
I haven't fully made up my mind about the practical impact of this bug,
I just came across it the hard way (rpi_push worked on uninitialized
data) while kicking
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
In order to allow further optimizations of xnlock, I started with
refactoring the related system.h. This improves the readability
significantly, IMHO. It also happen to reduce the text
Roland Stigge wrote:
Hi,
I hope you don't mind that we move this to the xenomai-core mailing list
with CC, since I fear the same questions will be raised again there at
some point.
Valid point!
Jan Kiszka wrote:
Now the next question: You are providing i386 packages so far. Do you
OK, to recall this message (and lift it to the list):
Leopold Palomo-Avellaneda wrote:
Hi,
this mail should be sent to Paul, but I would like to share with the xenomai
developers. Probably then should be sent to the xenomai-core list, but I have
looked the list and it has a high traffic
At least when SMP is enable, already __xnlock_get becomes far too
heavy-weighted for being inlined. xnlock_put is fine now, but looking
closer at the disassembly still revealed a lot of redundancy related to
acquiring and releasing xnlocks. In fact, we are mostly using
xnlock_get_irqsave and
Hi,
I'm happy to announce a patch series which actually started like hey,
let's check if we can have this nice FIFO ticket spinlock algorithm also
for our recursive xnlock. The result is a critical bug fix and a
massive text size reduction of nucleus and skins, both concerning SMP
systems.
In order to allow further optimizations of xnlock, I started with
refactoring the related system.h. This improves the readability
significantly, IMHO. It also happen to reduce the text size of
__xnlock_get a bit by avoid redundant rthal_processor_id read-outs.
Another quirk I happen to remove:
As the #ifdef forest was cut down, I once again looked at xnlock_put.
Why do you have this safety check for the owner also in production code?
Let's move it into the debug section. That leaves up with
static inline void xnlock_put(xnlock_t *lock)
{
xnlock_dbg_release(lock);
The root of all this: When Nick Piggin posted his first suggestion for
ticket spinlocks on LKML, I immediately liked the idea. For details
check LWN [1], in a nutshell: This algorithm enforces strict FIFO order
for the admission to contended spinlocks, thus it improves the
determinism on SMP
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
In order to allow further optimizations of xnlock, I started with
refactoring the related system.h. This improves the readability
significantly, IMHO. It also happen to reduce the text size of
__xnlock_get a bit by avoid redundant
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
At least when SMP is enable, already __xnlock_get becomes far too
heavy-weighted for being inlined. xnlock_put is fine now, but looking
closer at the disassembly still revealed a lot of redundancy related to
acquiring and releasing xnlocks
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
The root of all this: When Nick Piggin posted his first suggestion for
ticket spinlocks on LKML, I immediately liked the idea. For details
check LWN [1], in a nutshell: This algorithm enforces strict FIFO order
for the admission
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
At least when SMP is enable, already __xnlock_get becomes far too
heavy-weighted for being inlined. xnlock_put is fine now, but looking
closer at the disassembly still revealed
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
As the #ifdef forest was cut down, I once again looked at xnlock_put.
Why do you have this safety check for the owner also in production
code?
Because only one broken
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
The root of all this: When Nick Piggin posted his first suggestion for
ticket spinlocks on LKML, I immediately liked the idea. For details
check LWN [1], in a nutshell
Hi Gilles,
the backport from trunk was borken. This patch makes 2.4.x build again,
but - BIG-FAT-WARNING - I haven't tested the result.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
Index: xenomai-2.4.x/ksrc/skins/posix/syscall.c
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Would not it be simpler to put a pointer to the task_struct ? After
all,
it already has a pid, comm and mm, and a file descriptor will not
survive
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Would not it be simpler to put a pointer to the task_struct ? After all,
it already has a pid, comm and mm, and a file descriptor will not
survive a task_struct thanks to automatic closing of file descriptors
[Steven, I promised you this tool earlier, and now it runs. It /may/
help to understand some of your problems, at least it should give an
overview of your schedule...]
This is an update on how to get latest LTTng running with latest Xenomai!
For those who don't know what I'm talking about:
Gilles Chanteperdrix wrote:
On Mon, Feb 11, 2008 at 2:41 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
Juan Antonio Garcia Redondo wrote:
On 23/01/08 14:15, Gilles Chanteperdrix wrote:
On Jan 23, 2008 11:04 AM, Gilles Chanteperdrix
[EMAIL PROTECTED
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Would not it be simpler to put a pointer to the task_struct ?
After all,
it already has
Gilles Chanteperdrix wrote:
Juan Antonio Garcia Redondo wrote:
On 23/01/08 14:15, Gilles Chanteperdrix wrote:
On Jan 23, 2008 11:04 AM, Gilles Chanteperdrix
[EMAIL PROTECTED] wrote:
On Jan 23, 2008 7:52 AM, Juan Antonio Garcia Redondo
[EMAIL PROTECTED] wrote:
I see
901 - 1000 of 2091 matches
Mail list logo
