[Xenomai-core] I-pipe + latency tracing patch

[Xenomai-core] I-pipe + latency tracing patch

[Philippe Gerum]

I've just rolled out two patches, the first issue of the 1.1 series for 
x86, and the accompanying tracer patch contributed by Jan Kiszka and 
Luotao Fu. With the latter patch, the I-pipe shall trace the longest 
stalled path of the domain with the highest priority. Apply them in that 
order:

http://download.gna.org/adeos/patches/v2.6/adeos/i386/adeos-ipipe-2.6.14-i386-1.1-00.patch
http://download.gna.org/adeos/patches/v2.6/adeos/i386/tracer/ipipe-tracer-2.6.14-i386-1.1-00.patch

The core patch does not include Dmitry's work on the shared IRQ issues 
yet, but -01 will.

-- 

Philippe.

Re: [Xenomai-core] I-pipe + latency tracing patch

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1523 bytes --]

Philippe Gerum wrote:
> 
> I've just rolled out two patches, the first issue of the 1.1 series for
> x86, and the accompanying tracer patch contributed by Jan Kiszka and
> Luotao Fu. With the latter patch, the I-pipe shall trace the longest
> stalled path of the domain with the highest priority. Apply them in that
> order:
> 
> http://download.gna.org/adeos/patches/v2.6/adeos/i386/adeos-ipipe-2.6.14-i386-1.1-00.patch
> 
> http://download.gna.org/adeos/patches/v2.6/adeos/i386/tracer/ipipe-tracer-2.6.14-i386-1.1-00.patch
> 

Two remarks: First, the tracer patch claims more in its config option
than it actually provides - mea culpa. The patch itself does not contain
any instrumentation of ipipe. This has to be fixed. Meanwhile, please
have a look at this posting for instrumentation options:
https://mail.gna.org/public/xenomai-core/2005-12/msg00076.html

Philippe, do you remember the issues I described about my original
ipipe_trace.instr? How can we avoid too short worst-case traces due to
domain unstalling followed by re-stalling inside the same IRQ context?
Do you see further issues with this approach? I think it would be best
if we can provide a clean CONFIG_IPIPE_TRACE_STALLS for the highest (or
later maybe even for an arbitrary) domain together with the tracer.

And second, the separation between both patches is not clean. There are
tracer related fragments in the 1.1-00 base patch, intentionally? What's
the idea of the separated patches? I mean, doesn't this increase the
maintenance effort?

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [Adeos-main] Re: [Xenomai-core] I-pipe + latency tracing patch

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>I've just rolled out two patches, the first issue of the 1.1 series for
>>x86, and the accompanying tracer patch contributed by Jan Kiszka and
>>Luotao Fu. With the latter patch, the I-pipe shall trace the longest
>>stalled path of the domain with the highest priority. Apply them in that
>>order:
>>
>>http://download.gna.org/adeos/patches/v2.6/adeos/i386/adeos-ipipe-2.6.14-i386-1.1-00.patch
>>
>>http://download.gna.org/adeos/patches/v2.6/adeos/i386/tracer/ipipe-tracer-2.6.14-i386-1.1-00.patch
>>
> 
> 
> Two remarks: First, the tracer patch claims more in its config option
> than it actually provides - mea culpa. The patch itself does not contain
> any instrumentation of ipipe. This has to be fixed. Meanwhile, please
> have a look at this posting for instrumentation options:
> https://mail.gna.org/public/xenomai-core/2005-12/msg00076.html
> 
> Philippe, do you remember the issues I described about my original
> ipipe_trace.instr? How can we avoid too short worst-case traces due to
> domain unstalling followed by re-stalling inside the same IRQ context?
> Do you see further issues with this approach? I think it would be best
> if we can provide a clean CONFIG_IPIPE_TRACE_STALLS for the highest (or
> later maybe even for an arbitrary) domain together with the tracer.
> 

+static inline void ipipe_trace_stall(struct ipipe_domain *ipd, int code)
+{
+	if (__ipipe_pipeline_head_p(ipd) && (ipd != ipipe_root_domain))
+		ipipe_trace_begin(code);
+}
+
+static inline void ipipe_trace_unstall(struct ipipe_domain *ipd, int code)
+{
+	if (__ipipe_pipeline_head_p(ipd) && (ipd != ipipe_root_domain))
+		ipipe_trace_end(code);
+}

The test is wrong in both case. You need to check that ipd is above or 
equal to ipipe_current_domain in the pipeline. To determine that quickly 
while tracing, you will probably need to insert an integer giving the 
position of each domain into the ipipe_domain struct.

> And second, the separation between both patches is not clean. There are
> tracer related fragments in the 1.1-00 base patch, intentionally? What's
> the idea of the separated patches? I mean, doesn't this increase the
> maintenance effort?
> 

It's intentional, those (very few) bits always evaluate to false when 
the tracer is not in, and become conditional depending on the value of 
CONFIG_IPIPE_TRACE when the support available. IOW, they should be seen 
as sleeping hooks serving the purpose of allowing a further optional 
extension of the I-pipe.

The key issue here is not about ease of maintenance for us, but rather 
about ease of use for the people who don't necessarily want to drag 
what's fundamentally a debug infrastructure into the codebase of 
production systems, even if it's passive and can be compiled out. Adeos 
for x86 is about 151k without tracing, and goes beyond 189k with the 
tracer, which is nearly a 20% increase. Add to this that since a latency 
tracer is now available for vanilla Linux as an independent patch, it's 
likely wiser to allow people to keep the I-pipe tracing facility as a 
patch option too, so that you won't create conflicts (e.g. mcount).

In any case, I do see the tracer as a first-class citizen, regardless of 
the way we distribute it, be it inside the core support or as a broken 
out patch.

> Jan
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main


-- 

Philippe.

Re: [Adeos-main] Re: [Xenomai-core] I-pipe + latency tracing patch

[Philippe Gerum]

Philippe Gerum wrote:
> Jan Kiszka wrote:
> 
>> Philippe Gerum wrote:
>>
>>> I've just rolled out two patches, the first issue of the 1.1 series for
>>> x86, and the accompanying tracer patch contributed by Jan Kiszka and
>>> Luotao Fu. With the latter patch, the I-pipe shall trace the longest
>>> stalled path of the domain with the highest priority. Apply them in that
>>> order:
>>>
>>> http://download.gna.org/adeos/patches/v2.6/adeos/i386/adeos-ipipe-2.6.14-i386-1.1-00.patch 
>>>
>>>
>>> http://download.gna.org/adeos/patches/v2.6/adeos/i386/tracer/ipipe-tracer-2.6.14-i386-1.1-00.patch 
>>>
>>>
>>
>>
>> Two remarks: First, the tracer patch claims more in its config option
>> than it actually provides - mea culpa. The patch itself does not contain
>> any instrumentation of ipipe. This has to be fixed. Meanwhile, please
>> have a look at this posting for instrumentation options:
>> https://mail.gna.org/public/xenomai-core/2005-12/msg00076.html
>>
>> Philippe, do you remember the issues I described about my original
>> ipipe_trace.instr? How can we avoid too short worst-case traces due to
>> domain unstalling followed by re-stalling inside the same IRQ context?
>> Do you see further issues with this approach? I think it would be best
>> if we can provide a clean CONFIG_IPIPE_TRACE_STALLS for the highest (or
>> later maybe even for an arbitrary) domain together with the tracer.
>>
> 
> +static inline void ipipe_trace_stall(struct ipipe_domain *ipd, int code)
> +{
> +    if (__ipipe_pipeline_head_p(ipd) && (ipd != ipipe_root_domain))
> +        ipipe_trace_begin(code);
> +}
> +
> +static inline void ipipe_trace_unstall(struct ipipe_domain *ipd, int code)
> +{
> +    if (__ipipe_pipeline_head_p(ipd) && (ipd != ipipe_root_domain))
> +        ipipe_trace_end(code);
> +}
> 
> The test is wrong in both case. You need to check that ipd is above or 
> equal to ipipe_current_domain in the pipeline. To determine that quickly 
> while tracing, you will probably need to insert an integer giving the 
> position of each domain into the ipipe_domain struct.
> 
>> And second, the separation between both patches is not clean. There are
>> tracer related fragments in the 1.1-00 base patch, intentionally? What's
>> the idea of the separated patches? I mean, doesn't this increase the
>> maintenance effort?
>>
> 
> It's intentional, those (very few) bits always evaluate to false when 
> the tracer is not in, and become conditional depending on the value of 
> CONFIG_IPIPE_TRACE when the support available. IOW, they should be seen 
> as sleeping hooks serving the purpose of allowing a further optional 
> extension of the I-pipe.
> 
> The key issue here is not about ease of maintenance for us, but rather 
> about ease of use for the people who don't necessarily want to drag 
> what's fundamentally a debug infrastructure into the codebase of 
> production systems, even if it's passive and can be compiled out. Adeos 
> for x86 is about 151k without tracing, and goes beyond 189k with the 
> tracer, which is nearly a 20% increase. Add to this that since a latency

To be fair, it's rather 151k compared to 179k actually, which leads us 
to a 15% increase.

> tracer is now available for vanilla Linux as an independent patch, it's 
> likely wiser to allow people to keep the I-pipe tracing facility as a 
> patch option too, so that you won't create conflicts (e.g. mcount).
> 
> In any case, I do see the tracer as a first-class citizen, regardless of 
> the way we distribute it, be it inside the core support or as a broken 
> out patch.
> 
>> Jan
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Adeos-main mailing list
>> Adeos-main@domain.hid
>> https://mail.gna.org/listinfo/adeos-main
> 
> 
> 


-- 

Philippe.

Re: [Adeos-main] Re: [Xenomai-core] I-pipe + latency tracing patch

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4003 bytes --]

Philippe Gerum wrote:
> Jan Kiszka wrote:
> 
>> Philippe Gerum wrote:
>>
>>> I've just rolled out two patches, the first issue of the 1.1 series for
>>> x86, and the accompanying tracer patch contributed by Jan Kiszka and
>>> Luotao Fu. With the latter patch, the I-pipe shall trace the longest
>>> stalled path of the domain with the highest priority. Apply them in that
>>> order:
>>>
>>> http://download.gna.org/adeos/patches/v2.6/adeos/i386/adeos-ipipe-2.6.14-i386-1.1-00.patch
>>>
>>>
>>> http://download.gna.org/adeos/patches/v2.6/adeos/i386/tracer/ipipe-tracer-2.6.14-i386-1.1-00.patch
>>>
>>>
>>
>>
>> Two remarks: First, the tracer patch claims more in its config option
>> than it actually provides - mea culpa. The patch itself does not contain
>> any instrumentation of ipipe. This has to be fixed. Meanwhile, please
>> have a look at this posting for instrumentation options:
>> https://mail.gna.org/public/xenomai-core/2005-12/msg00076.html
>>
>> Philippe, do you remember the issues I described about my original
>> ipipe_trace.instr? How can we avoid too short worst-case traces due to
>> domain unstalling followed by re-stalling inside the same IRQ context?
>> Do you see further issues with this approach? I think it would be best
>> if we can provide a clean CONFIG_IPIPE_TRACE_STALLS for the highest (or
>> later maybe even for an arbitrary) domain together with the tracer.
>>
> 
> +static inline void ipipe_trace_stall(struct ipipe_domain *ipd, int code)
> +{
> +    if (__ipipe_pipeline_head_p(ipd) && (ipd != ipipe_root_domain))
> +        ipipe_trace_begin(code);
> +}
> +
> +static inline void ipipe_trace_unstall(struct ipipe_domain *ipd, int code)
> +{
> +    if (__ipipe_pipeline_head_p(ipd) && (ipd != ipipe_root_domain))
> +        ipipe_trace_end(code);
> +}
> 
> The test is wrong in both case. You need to check that ipd is above or
> equal to ipipe_current_domain in the pipeline. To determine that quickly
> while tracing, you will probably need to insert an integer giving the
> position of each domain into the ipipe_domain struct.

So the orderning in __ipipe_pipeline does say nothing about the priority
of the domain? Then this seems to have worked only by chance so far for me.

Anyway, fixing this does not seem to address the other issue I
mentioned. I once also traced the evaluation of those two conditions and
found no indication that this triggers the preliminary end-of-stall
reports I'm facing.

> 
>> And second, the separation between both patches is not clean. There are
>> tracer related fragments in the 1.1-00 base patch, intentionally? What's
>> the idea of the separated patches? I mean, doesn't this increase the
>> maintenance effort?
>>
> 
> It's intentional, those (very few) bits always evaluate to false when
> the tracer is not in, and become conditional depending on the value of
> CONFIG_IPIPE_TRACE when the support available. IOW, they should be seen
> as sleeping hooks serving the purpose of allowing a further optional
> extension of the I-pipe.

I see. Then these hooks are intended to keep the effort of breaking up
the patches low.

> 
> The key issue here is not about ease of maintenance for us, but rather
> about ease of use for the people who don't necessarily want to drag
> what's fundamentally a debug infrastructure into the codebase of
> production systems, even if it's passive and can be compiled out. Adeos
> for x86 is about 151k without tracing, and goes beyond 189k with the
> tracer, which is nearly a 20% increase. Add to this that since a latency
> tracer is now available for vanilla Linux as an independent patch, it's
> likely wiser to allow people to keep the I-pipe tracing facility as a
> patch option too, so that you won't create conflicts (e.g. mcount).

Actually, both traces should not collide as long as only one is active
at the same time.

Anyway, I already assumed that this more or less psychological aspect of
patch size makes a difference. I don't have a problem with this separation!

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [Adeos-main] Re: [Xenomai-core] I-pipe + latency tracing patch

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Jan Kiszka wrote:
>>
>>
>>>Philippe Gerum wrote:
>>>
>>>
>>>>I've just rolled out two patches, the first issue of the 1.1 series for
>>>>x86, and the accompanying tracer patch contributed by Jan Kiszka and
>>>>Luotao Fu. With the latter patch, the I-pipe shall trace the longest
>>>>stalled path of the domain with the highest priority. Apply them in that
>>>>order:
>>>>
>>>>http://download.gna.org/adeos/patches/v2.6/adeos/i386/adeos-ipipe-2.6.14-i386-1.1-00.patch
>>>>
>>>>
>>>>http://download.gna.org/adeos/patches/v2.6/adeos/i386/tracer/ipipe-tracer-2.6.14-i386-1.1-00.patch
>>>>
>>>>
>>>
>>>
>>>Two remarks: First, the tracer patch claims more in its config option
>>>than it actually provides - mea culpa. The patch itself does not contain
>>>any instrumentation of ipipe. This has to be fixed. Meanwhile, please
>>>have a look at this posting for instrumentation options:
>>>https://mail.gna.org/public/xenomai-core/2005-12/msg00076.html
>>>
>>>Philippe, do you remember the issues I described about my original
>>>ipipe_trace.instr? How can we avoid too short worst-case traces due to
>>>domain unstalling followed by re-stalling inside the same IRQ context?
>>>Do you see further issues with this approach? I think it would be best
>>>if we can provide a clean CONFIG_IPIPE_TRACE_STALLS for the highest (or
>>>later maybe even for an arbitrary) domain together with the tracer.
>>>
>>
>>+static inline void ipipe_trace_stall(struct ipipe_domain *ipd, int code)
>>+{
>>+    if (__ipipe_pipeline_head_p(ipd) && (ipd != ipipe_root_domain))
>>+        ipipe_trace_begin(code);
>>+}
>>+
>>+static inline void ipipe_trace_unstall(struct ipipe_domain *ipd, int code)
>>+{
>>+    if (__ipipe_pipeline_head_p(ipd) && (ipd != ipipe_root_domain))
>>+        ipipe_trace_end(code);
>>+}
>>
>>The test is wrong in both case. You need to check that ipd is above or
>>equal to ipipe_current_domain in the pipeline. To determine that quickly
>>while tracing, you will probably need to insert an integer giving the
>>position of each domain into the ipipe_domain struct.
> 
> 
> So the orderning in __ipipe_pipeline does say nothing about the priority
> of the domain? Then this seems to have worked only by chance so far for me.
> 

Of course it does. The thing is that your test must reflect the fact 
that stalling above and up to the current domain actually blocks the 
interrupts for the latter, and unstalling at least from your current 
domain unblocks them. The position value is just a suggestion to quickly 
compare the effective priority of two domains given their descriptor, 
without being stuck with the uncertainty of ipd->priority which might be 
the same for multiple domains, and without having to scan the pipeline 
top-down.

> Anyway, fixing this does not seem to address the other issue I
> mentioned. I once also traced the evaluation of those two conditions and
> found no indication that this triggers the preliminary end-of-stall
> reports I'm facing.
> 
> 
>>>And second, the separation between both patches is not clean. There are
>>>tracer related fragments in the 1.1-00 base patch, intentionally? What's
>>>the idea of the separated patches? I mean, doesn't this increase the
>>>maintenance effort?
>>>
>>
>>It's intentional, those (very few) bits always evaluate to false when
>>the tracer is not in, and become conditional depending on the value of
>>CONFIG_IPIPE_TRACE when the support available. IOW, they should be seen
>>as sleeping hooks serving the purpose of allowing a further optional
>>extension of the I-pipe.
> 
> 
> I see. Then these hooks are intended to keep the effort of breaking up
> the patches low.
> 

Yes. Actually, the latency tracer is merged into the Adeos CVS tree on 
top of the core system; it's just my patch release script that splits 
them since they are well separated. The remaining hooks do the necessary 
glue between them.

> 
>>The key issue here is not about ease of maintenance for us, but rather
>>about ease of use for the people who don't necessarily want to drag
>>what's fundamentally a debug infrastructure into the codebase of
>>production systems, even if it's passive and can be compiled out. Adeos
>>for x86 is about 151k without tracing, and goes beyond 189k with the
>>tracer, which is nearly a 20% increase. Add to this that since a latency
>>tracer is now available for vanilla Linux as an independent patch, it's
>>likely wiser to allow people to keep the I-pipe tracing facility as a
>>patch option too, so that you won't create conflicts (e.g. mcount).
> 
> 
> Actually, both traces should not collide as long as only one is active
> at the same time.
>

Unfortunately, we can't bet on this for the vanilla kernel part, who 
knows what's going to happen to this support in the future?

> Anyway, I already assumed that this more or less psychological aspect of
> patch size makes a difference. I don't have a problem with this separation!
> 
> Jan


-- 

Philippe.

Re: [Adeos-main] Re: [Xenomai-core] I-pipe + latency tracing patch

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3696 bytes --]

Philippe Gerum wrote:
> Jan Kiszka wrote:
> 
>> Philippe Gerum wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>
>>>> Philippe Gerum wrote:
>>>>
>>>>
>>>>> I've just rolled out two patches, the first issue of the 1.1 series
>>>>> for
>>>>> x86, and the accompanying tracer patch contributed by Jan Kiszka and
>>>>> Luotao Fu. With the latter patch, the I-pipe shall trace the longest
>>>>> stalled path of the domain with the highest priority. Apply them in
>>>>> that
>>>>> order:
>>>>>
>>>>> http://download.gna.org/adeos/patches/v2.6/adeos/i386/adeos-ipipe-2.6.14-i386-1.1-00.patch
>>>>>
>>>>>
>>>>>
>>>>> http://download.gna.org/adeos/patches/v2.6/adeos/i386/tracer/ipipe-tracer-2.6.14-i386-1.1-00.patch
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Two remarks: First, the tracer patch claims more in its config option
>>>> than it actually provides - mea culpa. The patch itself does not
>>>> contain
>>>> any instrumentation of ipipe. This has to be fixed. Meanwhile, please
>>>> have a look at this posting for instrumentation options:
>>>> https://mail.gna.org/public/xenomai-core/2005-12/msg00076.html
>>>>
>>>> Philippe, do you remember the issues I described about my original
>>>> ipipe_trace.instr? How can we avoid too short worst-case traces due to
>>>> domain unstalling followed by re-stalling inside the same IRQ context?
>>>> Do you see further issues with this approach? I think it would be best
>>>> if we can provide a clean CONFIG_IPIPE_TRACE_STALLS for the highest (or
>>>> later maybe even for an arbitrary) domain together with the tracer.
>>>>
>>>
>>> +static inline void ipipe_trace_stall(struct ipipe_domain *ipd, int
>>> code)
>>> +{
>>> +    if (__ipipe_pipeline_head_p(ipd) && (ipd != ipipe_root_domain))
>>> +        ipipe_trace_begin(code);
>>> +}
>>> +
>>> +static inline void ipipe_trace_unstall(struct ipipe_domain *ipd, int
>>> code)
>>> +{
>>> +    if (__ipipe_pipeline_head_p(ipd) && (ipd != ipipe_root_domain))
>>> +        ipipe_trace_end(code);
>>> +}
>>>
>>> The test is wrong in both case. You need to check that ipd is above or
>>> equal to ipipe_current_domain in the pipeline. To determine that quickly
>>> while tracing, you will probably need to insert an integer giving the
>>> position of each domain into the ipipe_domain struct.
>>
>>
>>
>> So the orderning in __ipipe_pipeline does say nothing about the priority
>> of the domain? Then this seems to have worked only by chance so far
>> for me.
>>
> 
> Of course it does. The thing is that your test must reflect the fact
> that stalling above and up to the current domain actually blocks the
> interrupts for the latter, and unstalling at least from your current
> domain unblocks them. The position value is just a suggestion to quickly
> compare the effective priority of two domains given their descriptor,
> without being stuck with the uncertainty of ipd->priority which might be
> the same for multiple domains, and without having to scan the pipeline
> top-down.

As I'm looking for the stall-time of the highest order domain, I don't
get this point for the stall. Regarding unstall: Is it the case that an
unstall below the highest domain currently stalled (e.g. Xenomai and
below is stalled, Linux gets unstalled) will also unstall the domains
above? In that case and when only looking at the highest domain (which I
will likely keep for simplicity), ipipe_trace_unstall() would simply
have to trace unconditionally.

> 
>> Anyway, fixing this does not seem to address the other issue I
>> mentioned. I once also traced the evaluation of those two conditions and
>> found no indication that this triggers the preliminary end-of-stall
>> reports I'm facing.
>>

...and this needs a closer look now.

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [Adeos-main] Re: [Xenomai-core] I-pipe + latency tracing patch

[Luotao Fu]

[-- Attachment #1: Type: text/plain, Size: 236 bytes --]

Hi,
As I've noticed, the tracer ist still not compeletly in the SVN trunk.
Thus it causes some problems (missing header files) while compiling the
timer Benchmark module.
Here is a small patch, which fix this problem.

Cheers
Luotao Fu

[-- Attachment #2: fix_timer.patch --]
[-- Type: text/x-patch, Size: 556 bytes --]

diff -uNr xenomai/ksrc/drivers/benchmark/timerbench.c xenomai-wd/ksrc/drivers/benchmark/timerbench.c
--- xenomai/ksrc/drivers/benchmark/timerbench.c 2006-01-04 16:22:05.000000000 +0100
+++ xenomai-wd/ksrc/drivers/benchmark/timerbench.c      2006-01-04 17:23:00.000000000 +0100
@@ -18,7 +18,9 @@

 #include <linux/module.h>
 #include <asm/semaphore.h>
-#include <linux/ipipe_trace.h>
+#ifdef CONFIG_IPIPE_TRACE
+ #include <linux/ipipe_trace.h>
+#endif /* CONFIG_IPIPE_TRACE */

 #include <xenomai/rtdm/rtbenchmark.h>
 #include <xenomai/rtdm/rtdm_driver.h>

Re: [Adeos-main] Re: [Xenomai-core] I-pipe + latency tracing patch

[Philippe Gerum]

Luotao Fu wrote:
> Hi,
> As I've noticed, the tracer ist still not compeletly in the SVN trunk.
>

And it won't actually. It is an optional part of the I-pipe layer.

  Thus it causes some problems (missing header files) while compiling the
> timer Benchmark module.
> Here is a small patch, which fix this problem.
> 

Applied, thanks.

> Cheers
> Luotao Fu
> 
> 
> ------------------------------------------------------------------------
> 
> diff -uNr xenomai/ksrc/drivers/benchmark/timerbench.c xenomai-wd/ksrc/drivers/benchmark/timerbench.c
> --- xenomai/ksrc/drivers/benchmark/timerbench.c 2006-01-04 16:22:05.000000000 +0100
> +++ xenomai-wd/ksrc/drivers/benchmark/timerbench.c      2006-01-04 17:23:00.000000000 +0100
> @@ -18,7 +18,9 @@
> 
>  #include <linux/module.h>
>  #include <asm/semaphore.h>
> -#include <linux/ipipe_trace.h>
> +#ifdef CONFIG_IPIPE_TRACE
> + #include <linux/ipipe_trace.h>
> +#endif /* CONFIG_IPIPE_TRACE */
> 
>  #include <xenomai/rtdm/rtbenchmark.h>
>  #include <xenomai/rtdm/rtdm_driver.h>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main


-- 

Philippe.

Re: [Adeos-main] Re: [Xenomai-core] I-pipe + latency tracing patch

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Jan Kiszka wrote:
>>
>>
>>>Philippe Gerum wrote:
>>>
>>>
>>>>Jan Kiszka wrote:
>>>>
>>>>
>>>>
>>>>>Philippe Gerum wrote:
>>>>>
>>>>>
>>>>>
>>>>>>I've just rolled out two patches, the first issue of the 1.1 series
>>>>>>for
>>>>>>x86, and the accompanying tracer patch contributed by Jan Kiszka and
>>>>>>Luotao Fu. With the latter patch, the I-pipe shall trace the longest
>>>>>>stalled path of the domain with the highest priority. Apply them in
>>>>>>that
>>>>>>order:
>>>>>>
>>>>>>http://download.gna.org/adeos/patches/v2.6/adeos/i386/adeos-ipipe-2.6.14-i386-1.1-00.patch
>>>>>>
>>>>>>
>>>>>>
>>>>>>http://download.gna.org/adeos/patches/v2.6/adeos/i386/tracer/ipipe-tracer-2.6.14-i386-1.1-00.patch
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>Two remarks: First, the tracer patch claims more in its config option
>>>>>than it actually provides - mea culpa. The patch itself does not
>>>>>contain
>>>>>any instrumentation of ipipe. This has to be fixed. Meanwhile, please
>>>>>have a look at this posting for instrumentation options:
>>>>>https://mail.gna.org/public/xenomai-core/2005-12/msg00076.html
>>>>>
>>>>>Philippe, do you remember the issues I described about my original
>>>>>ipipe_trace.instr? How can we avoid too short worst-case traces due to
>>>>>domain unstalling followed by re-stalling inside the same IRQ context?
>>>>>Do you see further issues with this approach? I think it would be best
>>>>>if we can provide a clean CONFIG_IPIPE_TRACE_STALLS for the highest (or
>>>>>later maybe even for an arbitrary) domain together with the tracer.
>>>>>
>>>>
>>>>+static inline void ipipe_trace_stall(struct ipipe_domain *ipd, int
>>>>code)
>>>>+{
>>>>+    if (__ipipe_pipeline_head_p(ipd) && (ipd != ipipe_root_domain))
>>>>+        ipipe_trace_begin(code);
>>>>+}
>>>>+
>>>>+static inline void ipipe_trace_unstall(struct ipipe_domain *ipd, int
>>>>code)
>>>>+{
>>>>+    if (__ipipe_pipeline_head_p(ipd) && (ipd != ipipe_root_domain))
>>>>+        ipipe_trace_end(code);
>>>>+}
>>>>
>>>>The test is wrong in both case. You need to check that ipd is above or
>>>>equal to ipipe_current_domain in the pipeline. To determine that quickly
>>>>while tracing, you will probably need to insert an integer giving the
>>>>position of each domain into the ipipe_domain struct.
>>>
>>>
>>>
>>>So the orderning in __ipipe_pipeline does say nothing about the priority
>>>of the domain? Then this seems to have worked only by chance so far
>>>for me.
>>>
>>
>>Of course it does. The thing is that your test must reflect the fact
>>that stalling above and up to the current domain actually blocks the
>>interrupts for the latter, and unstalling at least from your current
>>domain unblocks them. The position value is just a suggestion to quickly
>>compare the effective priority of two domains given their descriptor,
>>without being stuck with the uncertainty of ipd->priority which might be
>>the same for multiple domains, and without having to scan the pipeline
>>top-down.
> 
> 
> As I'm looking for the stall-time of the highest order domain, I don't
> get this point for the stall.

My point was about defining the proper test to check for the stalled 
state, regardless of the number of domains above Linux in the pipeline.

  Regarding unstall: Is it the case that an
> unstall below the highest domain currently stalled (e.g. Xenomai and
> below is stalled, Linux gets unstalled) will also unstall the domains
> above?

If the pipeline shows like: Domain(A,stalled) -- (B) -- (C)
then unstalling C won't change the situation: the interrupts will still 
be blocked by stage A.

  In that case and when only looking at the highest domain (which I
> will likely keep for simplicity), ipipe_trace_unstall() would simply
> have to trace unconditionally.
> 
> 
>>>Anyway, fixing this does not seem to address the other issue I
>>>mentioned. I once also traced the evaluation of those two conditions and
>>>found no indication that this triggers the preliminary end-of-stall
>>>reports I'm facing.
>>>
> 
> 
> ...and this needs a closer look now.
> 
> Jan
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main


-- 

Philippe.