Re: [Xenomai-core] [Xenomai-help] measuring tasks execution time

[Jan Kiszka <jan.kiszka@domain.hid>]

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

Daniel Simon wrote:
> On Fri, 08 Jun 2007 13:20:11 +0200
> Jan Kiszka <jan.kiszka@domain.hid> wrote:
> 
>> Daniel Simon wrote:
>>> On Thu, 07 Jun 2007 19:44:47 +0200
>>> Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>>
>>> Hello, opening a new thead forking from the one opened yesterday by Arnaud
>>> Desvages
>> I moved the thread to xenomai-core, hope you don't mind.
> 
> OK,  I guess it is the right place
> [...]
>>> Our goal is computing the accumulated cost of some selected real-time tasks
>>> to get an image of the  cpu load.
>>>
>>> What we need is a record of  the accumulated execution time of the
>>> rt_tasks (not the response time, hence the instants when the task is
>>> preempted or suspended must not be counted).
>>> This record must be accessible at any time, either from the calling
>>> task or by another one.  
>>>
>>> Our current patch only does that for tasks running in primary mode (and
>>> moreover the measure seems not correctly updated for the calling
>>> task record).  
>>>
>>> Thus we would be very happy to get an improved instrumentation api.
>>> I understand that  xnstat_runtime_update() handles the measure we need? 
>> It was designed to collect precise runtime statistics to be displayed in
>> /proc/xenomai/stat. We would just have to keep a total counter for each
>> task as dumping /proc resets the statistics ATM.
>>
>>> Making it available, e.g.  via a rt_task_inquire call, would be great! 
>> Well, the best (==most comfortable :o) ) way from my POV would be if you
>> could try rebasing your work on your own first. Questions, even on minor
>> details, are always welcome, review on patches will be provided. Should
>> be no problem to get this into Xenomai 2.4.
>>
>> The rough to-do list would be:
>>
>>  o add some persistent runtimer counter to xnthread::stat and maintain
>>    it
>>  o introduce an xnpod service (inline function) to obtain it (let that
>>    thing return [0..LONGLONG_MAX] when stats are available, -1
>>    otherwise)
>>  o export the runtime via struct rt_task_info, maybe also the task start
>>    time
>>
>> Jan
>>
> I am afraid that it is far beyond my own programming capabilities, and I have no
> longer skilled enough students at hand...
> Anyway there are some highly skilled (and overloaded) engineers around, i'll try
> to hire one of them!

Any support is welcome, offers still stand!

Damn, meanwhile I started thinking about this more than I wanted. So,
whoever will implement it, a few more remarks/suggestions:

- Considering the existing xnthread:stime and its usage (I didn't found
  a place), I would say just add another xnstat_runtime_t to
  xnthread::stat for life-time statistics and delete stime.

- Note that migrating life-time stats between CPUs requires rebasing the
  thread start time properly.

- And then I think we could also dump the life-time CPU usage based on
  that new data in /proc/xenomai/stat. Would be a nice test besides the
  native API extension... :->

Jan


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