[Adeos-main] Re: Adeos-cvs Digest, Vol 10, Issue 11

[Adeos-main] Re: Adeos-cvs Digest, Vol 10, Issue 11

[Jan Kiszka]

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

adeos-cvs-request@domain.hid wrote:
> ...
> Commit from rpm (2006-04-26 17:41 CEST)
> ---------------
> 
> Make IPIPE_TRACE_PATHS configurable
> 
>   ipipe  v2.6/common/kernel/ipipe/tracer.c       1.10
>   ipipe  v2.6/common/kernel/ipipe/Kconfig.trace  1.4

From a quick glance it appears to me you provided a nice interface to
break some stuff :). At least the explanation is not correct.

Those four paths are required to 1) always have an active path at hand
for recording, 2+3) keep the latest max or frozen path, and 4) escape
with to an alternative slot during max/frozen updates in case the
previous one is currently locked for output or whatever and cannot
become the new active path.

So, the absolute minimum is 3 when there is definitely no concurrent
usage of ipipe_trace_begin/end vs. ipipe_trace_freeze (remember that
users may want to define their own begin/end points if
IPIPE_TRACE_IRQSOFF is not set). Raising it above 4 is of no practical
use so far.

What is your idea behind it?

Jan


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

[Adeos-main] Re: Adeos-cvs Digest, Vol 10, Issue 11

[Philippe Gerum]

Jan Kiszka wrote:
> adeos-cvs-request@domain.hid wrote:
> 
>>...
>>Commit from rpm (2006-04-26 17:41 CEST)
>>---------------
>>
>>Make IPIPE_TRACE_PATHS configurable
>>
>>  ipipe  v2.6/common/kernel/ipipe/tracer.c       1.10
>>  ipipe  v2.6/common/kernel/ipipe/Kconfig.trace  1.4
> 
> 
> From a quick glance it appears to me you provided a nice interface to
> break some stuff :). At least the explanation is not correct.
> 
> Those four paths are required to 1) always have an active path at hand
> for recording, 2+3) keep the latest max or frozen path, and 4) escape
> with to an alternative slot during max/frozen updates in case the
> previous one is currently locked for output or whatever and cannot
> become the new active path.
> 
> So, the absolute minimum is 3 when there is definitely no concurrent
> usage of ipipe_trace_begin/end vs. ipipe_trace_freeze (remember that
> users may want to define their own begin/end points if
> IPIPE_TRACE_IRQSOFF is not set). Raising it above 4 is of no practical
> use so far.
> 
> What is your idea behind it?
> 

My idea is that 4 paths consume way too much memory and causes my 
embedded ppc setup to choke at boot. The usual culprits like a bad 
download address passed to u-boot and friends are not involved this 
time, so until I figure out what on earth is causing this havoc, I'd 
like to be able to lower this value to 2 by configuration.

-- 

Philippe.

[Adeos-main] Re: Adeos-cvs Digest, Vol 10, Issue 11

[Jan Kiszka]

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

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> adeos-cvs-request@domain.hid wrote:
>>
>>> ...
>>> Commit from rpm (2006-04-26 17:41 CEST)
>>> ---------------
>>>
>>> Make IPIPE_TRACE_PATHS configurable
>>>
>>>  ipipe  v2.6/common/kernel/ipipe/tracer.c       1.10
>>>  ipipe  v2.6/common/kernel/ipipe/Kconfig.trace  1.4
>>
>>
>> From a quick glance it appears to me you provided a nice interface to
>> break some stuff :). At least the explanation is not correct.
>>
>> Those four paths are required to 1) always have an active path at hand
>> for recording, 2+3) keep the latest max or frozen path, and 4) escape
>> with to an alternative slot during max/frozen updates in case the
>> previous one is currently locked for output or whatever and cannot
>> become the new active path.
>>
>> So, the absolute minimum is 3 when there is definitely no concurrent
>> usage of ipipe_trace_begin/end vs. ipipe_trace_freeze (remember that
>> users may want to define their own begin/end points if
>> IPIPE_TRACE_IRQSOFF is not set). Raising it above 4 is of no practical
>> use so far.
>>
>> What is your idea behind it?
>>
> 
> My idea is that 4 paths consume way too much memory and causes my
> embedded ppc setup to choke at boot. The usual culprits like a bad
> download address passed to u-boot and friends are not involved this
> time, so until I figure out what on earth is causing this havoc, I'd
> like to be able to lower this value to 2 by configuration.
> 

Then better make IPIPE_TRACE_POINTS configurable. Also the whole
ipipe_trace_begin/end interface could be made optional so that the
number of paths could be reduced by _1_ (not more...).

Jan


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

[Adeos-main] Re: Adeos-cvs Digest, Vol 10, Issue 11

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Jan Kiszka wrote:
>>
>>>adeos-cvs-request@domain.hid wrote:
>>>
>>>
>>>>...
>>>>Commit from rpm (2006-04-26 17:41 CEST)
>>>>---------------
>>>>
>>>>Make IPIPE_TRACE_PATHS configurable
>>>>
>>>> ipipe  v2.6/common/kernel/ipipe/tracer.c       1.10
>>>> ipipe  v2.6/common/kernel/ipipe/Kconfig.trace  1.4
>>>
>>>
>>>From a quick glance it appears to me you provided a nice interface to
>>>break some stuff :). At least the explanation is not correct.
>>>
>>>Those four paths are required to 1) always have an active path at hand
>>>for recording, 2+3) keep the latest max or frozen path, and 4) escape
>>>with to an alternative slot during max/frozen updates in case the
>>>previous one is currently locked for output or whatever and cannot
>>>become the new active path.
>>>
>>>So, the absolute minimum is 3 when there is definitely no concurrent
>>>usage of ipipe_trace_begin/end vs. ipipe_trace_freeze (remember that
>>>users may want to define their own begin/end points if
>>>IPIPE_TRACE_IRQSOFF is not set). Raising it above 4 is of no practical
>>>use so far.
>>>
>>>What is your idea behind it?
>>>
>>
>>My idea is that 4 paths consume way too much memory and causes my
>>embedded ppc setup to choke at boot. The usual culprits like a bad
>>download address passed to u-boot and friends are not involved this
>>time, so until I figure out what on earth is causing this havoc, I'd
>>like to be able to lower this value to 2 by configuration.
>>
> 
> 
> Then better make IPIPE_TRACE_POINTS configurable. Also the whole
> ipipe_trace_begin/end interface could be made optional so that the
> number of paths could be reduced by _1_ (not more...).
> 

Ok, I'll do that. Hopefully, this will help the boot issue too.

-- 

Philippe.

Re: [Adeos-main] Re: Adeos-cvs Digest, Vol 10, Issue 11

[Philippe Gerum]

Philippe Gerum wrote:
> Jan Kiszka wrote:
> 
>> adeos-cvs-request@domain.hid wrote:
>>
>>> ...
>>> Commit from rpm (2006-04-26 17:41 CEST)
>>> ---------------
>>>
>>> Make IPIPE_TRACE_PATHS configurable
>>>
>>>  ipipe  v2.6/common/kernel/ipipe/tracer.c       1.10
>>>  ipipe  v2.6/common/kernel/ipipe/Kconfig.trace  1.4
>>
>>
>>
>> From a quick glance it appears to me you provided a nice interface to
>> break some stuff :). At least the explanation is not correct.
>>
>> Those four paths are required to 1) always have an active path at hand
>> for recording, 2+3) keep the latest max or frozen path, and 4) escape
>> with to an alternative slot during max/frozen updates in case the
>> previous one is currently locked for output or whatever and cannot
>> become the new active path.
>>
>> So, the absolute minimum is 3 when there is definitely no concurrent
>> usage of ipipe_trace_begin/end vs. ipipe_trace_freeze (remember that
>> users may want to define their own begin/end points if
>> IPIPE_TRACE_IRQSOFF is not set). Raising it above 4 is of no practical
>> use so far.
>>
>> What is your idea behind it?
>>
> 
> My idea is that 4 paths consume way too much memory and causes my 
> embedded ppc setup to choke at boot. The usual culprits like a bad 
> download address passed to u-boot and friends are not involved this 
> time, so until I figure out what on earth is causing this havoc, I'd 
> like to be able to lower this value to 2 by configuration.
> 

Since the above is not an option, maybe we could try reducing the number 
of trace points instead? but I'm not sure if this is going to be enough. 
This said, unless there is some hard limit on this too, this would be 
useful to export a configuration switch for that.

-- 

Philippe.

Re: [Adeos-main] Re: Adeos-cvs Digest, Vol 10, Issue 11

[Philippe Gerum]

Jan Kiszka wrote:
> adeos-cvs-request@domain.hid wrote:
> 
>>...
>>Commit from rpm (2006-04-26 17:41 CEST)
>>---------------
>>
>>Make IPIPE_TRACE_PATHS configurable
>>
>>  ipipe  v2.6/common/kernel/ipipe/tracer.c       1.10
>>  ipipe  v2.6/common/kernel/ipipe/Kconfig.trace  1.4
> 
> 
> From a quick glance it appears to me you provided a nice interface to
> break some stuff :). At least the explanation is not correct.
> 
> Those four paths are required to 1) always have an active path at hand
> for recording, 2+3) keep the latest max or frozen path, and 4) escape
> with to an alternative slot during max/frozen updates in case the
> previous one is currently locked for output or whatever and cannot
> become the new active path.
> 
> So, the absolute minimum is 3 when there is definitely no concurrent
> usage of ipipe_trace_begin/end vs. ipipe_trace_freeze (remember that
> users may want to define their own begin/end points if
> IPIPE_TRACE_IRQSOFF is not set). Raising it above 4 is of no practical
> use so far.
> 

Oh, wait, you've just explained why passing -f to the latency test 
freezes my board! Thanks :o)

-- 

Philippe.

Re: [Adeos-main] Re: Adeos-cvs Digest, Vol 10, Issue 11

[Jan Kiszka]

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

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> adeos-cvs-request@domain.hid wrote:
>>
>>> ...
>>> Commit from rpm (2006-04-26 17:41 CEST)
>>> ---------------
>>>
>>> Make IPIPE_TRACE_PATHS configurable
>>>
>>>  ipipe  v2.6/common/kernel/ipipe/tracer.c       1.10
>>>  ipipe  v2.6/common/kernel/ipipe/Kconfig.trace  1.4
>>
>>
>> From a quick glance it appears to me you provided a nice interface to
>> break some stuff :). At least the explanation is not correct.
>>
>> Those four paths are required to 1) always have an active path at hand
>> for recording, 2+3) keep the latest max or frozen path, and 4) escape
>> with to an alternative slot during max/frozen updates in case the
>> previous one is currently locked for output or whatever and cannot
>> become the new active path.
>>
>> So, the absolute minimum is 3 when there is definitely no concurrent
>> usage of ipipe_trace_begin/end vs. ipipe_trace_freeze (remember that
>> users may want to define their own begin/end points if
>> IPIPE_TRACE_IRQSOFF is not set). Raising it above 4 is of no practical
>> use so far.
>>
> 
> Oh, wait, you've just explained why passing -f to the latency test
> freezes my board! Thanks :o)
> 

Famous last words while reaching out the finger:

"Hey, what is this knob for?" :)

Jan


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

Re: [Adeos-main] Re: Adeos-cvs Digest, Vol 10, Issue 11

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Jan Kiszka wrote:
>>
>>>adeos-cvs-request@domain.hid wrote:
>>>
>>>
>>>>...
>>>>Commit from rpm (2006-04-26 17:41 CEST)
>>>>---------------
>>>>
>>>>Make IPIPE_TRACE_PATHS configurable
>>>>
>>>> ipipe  v2.6/common/kernel/ipipe/tracer.c       1.10
>>>> ipipe  v2.6/common/kernel/ipipe/Kconfig.trace  1.4
>>>
>>>
>>>From a quick glance it appears to me you provided a nice interface to
>>>break some stuff :). At least the explanation is not correct.
>>>
>>>Those four paths are required to 1) always have an active path at hand
>>>for recording, 2+3) keep the latest max or frozen path, and 4) escape
>>>with to an alternative slot during max/frozen updates in case the
>>>previous one is currently locked for output or whatever and cannot
>>>become the new active path.
>>>
>>>So, the absolute minimum is 3 when there is definitely no concurrent
>>>usage of ipipe_trace_begin/end vs. ipipe_trace_freeze (remember that
>>>users may want to define their own begin/end points if
>>>IPIPE_TRACE_IRQSOFF is not set). Raising it above 4 is of no practical
>>>use so far.
>>>
>>
>>Oh, wait, you've just explained why passing -f to the latency test
>>freezes my board! Thanks :o)
>>
> 
> 
> Famous last words while reaching out the finger:
> 
> "Hey, what is this knob for?" :)
> 

Yeah, hopefully, next time I'm naive and optimistic, the fine print on 
the button won't say "ejection seat"...

-- 

Philippe.