Philippe Gerum wrote:
>> ...
>>>> xeno-kill-ipipe_processor_id.patch
>>>>     Refreshed cleanup patch to remove ipipe_processor_id completely.
>>> The logic of this patch is flawed. rthal_processor_id() already implies
>>> rawness wrt how we fetch the current CPU number, so
>>> rthal_raw_processor_id() is redundant, and xnarch_raw_current_cpu() too
>> It isn't when you take a look at the corresponding I-pipe patch as well:
>> This enables debug instrumentation of smp_processor_id to validate also
>> the atomicity of Xenomai core code /wrt cpuid handling!
> Nope, not for archs which do _not_ have a stack-insensitive
> smp_processor_id() and get_current() yet (if it's even possible for all
> of them, since the in-kernel ABI would likely have to be amended for
> reserving the PDA register). Some archs even have stack-insensitive
> get_current(), but stack-sensitive current_thread_info(), so we might be
> toast in a way or another.
> I'm not arguing that the I-pipe changes you suggest have no value in the
> 2.6.20/x86* contexts for instance, but since they also affect the generic
> code area, they can't work for all our supported configurations right
> now. For instance, on an I-pipe setup with a non-heading Xenomai domain
> and DEBUG_PREEMPT enabled, a kernel-based Xenomai thread calling
> smp_processor_id() from a stalled context (which would be legal) would
> _require_ preemption control macros and get_current() to be
> stack-insensitive. At that point, we would have some problem propagating
> this assumptions to the generic Xenomai core, specifically for the
> Blackfin and ARM variants, which do not have stack-insensitive accessors
> here.
> Also, my point is that we don't want to change the usability of
> rthal_processor_id(). So either it does not change with this patch, and
> the raw* forms are useless, or it changes, and this is a no-go. Keep in
> mind that a number of external modules may rely on this aspect already;
> so either we kill rthal_processor_id() completely to force a proper
> update in depending code, or we keep the basic assumptions about the
> usability context unchanged, but we just cannot make the situation more
> fragile for the out of tree code by changing such a fundamental
> assumption (i.e. that rthal_processor_id() is context-agnostic).

Ok, I see it's too early. Let's put this back into the drawer until we
might solve the stack-sensitiveness issue for all archs (as we recently
started to discuss). I will rework the I-pipe patches so that we can
make use of some parts of them already now.

>>> for the same reason. Additionally, xnpod_current_sched() also implies to
>>> use a raw accessor to the CPU number, so xnpod_current_raw_sched() is
>>> pointless. For this reason, we must be extra-careful about replacing
>>> rthal_processor_id() with smp_processor_id(), because 1) we may want to
>>> bypass DEBUG_PREEMPT checks sometimes, 2) not all supported archs do
>>> have a stack-insensitive smp_processor_id() implementation yet
>>> (blackfin, ARM, and Linux/x86 2.4).
>> For 1) see ipipe again, but 2), granted, is a problem. Likely the cut is
>> too radical and we must leave the infrastructure in place. Still, making
>> use of DEBUG_PREEMPT also for Xenomai is IMHO worth some changes that
>> will then at least have effect on a subset of archs.
> It becomes very useful precisely because ipipe_processor_id() gets
> killed.
>>> To answer the inlined question about the need to initialize the ->sched
>>> field when setting up a timer, I would say yes, we have to set this up
>>> too. It might seem a bit silly, but nothing would prevent a migration
>>> call to occur for a just initialized timer, in which case, we would need
>>> the sched pointer to reflect the current situation (i.e. at init time).
>> But what would be the effect of a wrong sched until the timer is
>> started?
> panic. See the code flow from xntimer_start_*periodic for instance, up
> to the point where the timer is enqueued.

With wrong I meant valid sched, but for an incorrect CPU.

>>  Anyway, if you say it does matter, my instrumentation would
>> have caught the first bug in Xenomai! That xnpod_raw_current_sched() is
>> there because xntimer_init is used in non-atomic contexts (I got
>> warnings from DEBUG_PREEMPT).
> Thread migration in Xenomai only happens upon request from the migrating
> thread itself, so it becomes an issue if the caller belongs to the Linux
> domain (i.e. preemption in init_module, the rest is not much

...or preemption during shadow thread creation. But this requires the
that Linux thread to be shadowed has no clearly defined single-CPU
affinity and might happen to be pushed around by a loadbalancer during
init. This sounds like a fatal user error /wrt RT.

> preemptible), in which case the timer might be queued on a different CPU
> than the thread's. But since we don't migrate timers upon
> sched_setaffinity() requests already, but only upon
> xnpod_migrate_thread() calls, this seems a non-issue. We would have an
> extra cost for managing a remote timer, but this would work, and above
> all, this would be no different from enduring such migration caused by
> sched_setaffinity() outside of xntimer_init().

Agreed. There is the risk that the timer is attached to one CPU while
the thread starts on some other, but this only means suboptimal
performance and would be due to a user mistake.

>>>> librtutils.patch
>>>>     My original librtprint patch. I now renamed the library to
>>>>     librtutils to express that more stuff beyond rt_print may find its
>>>>     home here in the future. Hopefully acceptable now.
>>> Will merge, but... since I'm something of a pain, I'm still pondering
>>> whether rtutils is our best shot for picking up a name here. We already
>>> have src/utils, so we would add src/librtutils as yet another set of
>>> utilities; I'm not sure both belong to the same class of helpers.
>> /me hesitated as well and put the "lib" prefix into the directory name.
>> So I'm all ears for a better name!
> TssTssTss... _You_ got the brain, _I_ am the cumbersome one.

But my brain needs some pointers what _you_ would be happy with. Is your
current problem only related to the clash librtutils vs. utils, or don't
you like the term "rtutils" at all? If it's the former, would moving
"utils" to "tools" raise or lower your pain?

>>>> rtsystrace-v2.patch
>>>>     Updated proposal to add rt_print-based Xenomai syscall tracing.
>>>>     Still in early stage, and I'm lacking feedback on this approach, if
>>>>     it makes sense to pursue it.
>>> Gasp. I really don't like the idea of having tons of explicit trace
>>> points spread all over the code, this just makes the task of reading it
>>> a total nightmare. There are some user-space tracing infrastructure
>>> already, starting with LTTng, or maybe older ones like Ctrace, with or
>>> without automatic instrumentation of the source files.
>>> We may want to get some facts about those before reinventing a square
>>> wheel.
>> Let me elaborate about the motivation a bit more: My idea is to have an
>> rt-safe replacement for strace. The latter is based on ptrace, requires
>> evil signals, and is far to invasive for tracing high-speed RT
>> applications IMHO (even if we had that RT-safe). But with low-impact,
>> per-process rt_printf, we have a pure user space mechanism at hand that
>> you can quickly set up for a single RT application (using your private
>> libs e.g.). No need to have an LTTng-prepared kernel, no need to trace
>> the whole system if you only want to know where your damn applications
>> now hangs again, no need to disturb other RT users with your debugging
>> stuff.
>> But I agree, the source code impact on the skin libs is far from being
>> negligible. Maybe we can find a smarter solution, something that just
>> hooks into the library calls (reminds me of --wrap...) to capture entry
>> parameters and then the returned values. This will still require some
>> work (for each instrumented library function), but we might be able to
>> do this out-of-line.
> At some point, I think we should really put some brain cycles into
> looking into Valgrind, and evaluate the actual cost of adapting it to
> our needs (for both the existing memory tracker skin, and maybe a trace
> skin too).

Valgrind is not a replacement for strace, even if it would work for
multi-threaded strickly timed RT apps (which I doubt, I _did_ look at it
already, understood that it requires a complex and temporal invasive VM,
and also read their warnings regarding standard pthread support). This
is a widely orthogonal issue, so please let us come back to my original

>>>> lttng.patch
>>>>     Very rough patch to make LTTng work with Xenomai again. This patch
>>>>     tries to follow Jean-Olivier Villemure's original work very closely
>>>>     to get something working first. Needs more cleanups and enhancements
>>>>     as I explained earlier in the LTTng announcement.
>>> Will merge to ease further work on this feature. xenoltt.xml might be
>>> left in another directory than src/utils, or at least in a separate
>>> subdir, like can/.
>> Note that the patch is a big fat construction site (see the earlier
>> announcement). I'm happy to see your interest, and we should already
>> discuss details like the location of xenoltt.xml. But I think it's not
>> yet ready for merge.
>> I would like to get the structure right first (multiple probe modules),
>> and I'm lacking the understanding about what the Xenomai plugin for LTTV
>> is actually able to do, what kind of trace point formats it needs to
>> work correctly. Well, this situation can quickly improve once we play a
>> bit more with it, but resources remain limited.
> The decision is rather simple here: whether our current LTT
> instrumentation works and is usable with decent LTT releases, and we
> should keep it, waiting for the new LTTng support to mature out of tree.

Current LTT support is useless for a fairly long time as we had no LTT
patches for I-pipe - also for a long time. From this POV, we can happily
change the code without causing regressions (as long as it builds, of

> Or, this is not the case, and we would be better off putting this patch
> where it has a better chance to be seen and evaluated, i.e. into the
> development tree. So the basic issue here is that we might have to make
> the patch you sent working well enough to trigger interest in improving
> it, unless it does already. What's the situation regarding this?

Daniel indicated interest in looking at this, but he is fairly busy for
the near future. No further feedback so far.

My suggestion is to keep the patch out-of-tree for now. Everyone
interested in trying LTTng needs patching anyway (LTTV, ipipe, Xenomai).
I will keep this patch in my stack and take care that it remains applicable.

In the meantime, Xenomai should align with the latest kernel again
(2.6.21/22) so that also the LTTng patches can be updated, simplifying
the patch process and maturing our own probing support (like "MARK" ->
"trace_mark"). I will look at the Xenomai side again to make it more
quickly mergeable. With ipipe_processor_id not vanishing, there remains
some work on the I-pipe side of LTTng as well (for non-x86 support).


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to