Daniel Simon wrote:
> On Thu, 07 Jun 2007 19:44:47 +0200
> Jan Kiszka <[EMAIL PROTECTED]> 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.

>> Hmm, the patch looks like it consequently reimplements existing runtime
>> statistics instead of reusing them as a foundation...
> Yes, might be simpler now. This patch has been done in urgency upon
> xenomai 2.1 and was more or less sleeping since one year. It has been weakly

This explains why your changes are right below the xnstat infrastructure

> tested, only on Pentium 3 cpus.
>> Anyway, I think we could discuss some API extension of Xenomai (for
>> native, probably via  ). Likely we would keep this report
>> optional, ie. make it return -1 or so if CONFIG_XENO_OPT_STATS is off.
>> Tracking stats is not as costly as other instrumentations, but it's also
>> not free. If you are interested, let us know. It won't be a one-liner,
>> but it doesn't look like it has to be as invasive as your approach.
> 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
 o introduce an xnpod service (inline function) to obtain it (let that
   thing return [0..LONGLONG_MAX] when stats are available, -1
 o export the runtime via struct rt_task_info, maybe also the task start


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to