All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Daniel Simon <Daniel.Simon@domain.hid>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] [Xenomai-help] measuring tasks execution time
Date: Fri, 08 Jun 2007 13:20:11 +0200	[thread overview]
Message-ID: <46693B6B.1010201@domain.hid> (raw)
In-Reply-To: <20070608124927.1b789a9e@domain.hid>

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

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.

> 
>> 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
code...

> 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
   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


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

  reply	other threads:[~2007-06-08 11:20 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-07 16:23 [Xenomai-help] real time task disapears... memory problem ? desvages
2007-06-07 17:44 ` Jan Kiszka
2007-06-08 10:49   ` [Xenomai-help] measuring tasks execution time Daniel Simon
2007-06-08 11:20     ` Jan Kiszka [this message]
2007-06-08 13:09       ` [Xenomai-core] " Daniel Simon
2007-06-08 15:24         ` Jan Kiszka
2007-06-08 16:04           ` Jan Kiszka
2007-06-25 15:51       ` [Xenomai-core] " Daniel Simon
2007-06-25 16:55         ` Jan Kiszka
2007-06-27  8:57           ` Daniel Simon
2007-06-27 11:56             ` Jan Kiszka
2007-06-29 14:43               ` Daniel Simon
2007-06-29 15:00                 ` Jan Kiszka
2007-06-29 15:29                   ` Daniel Simon
2007-06-29 15:47                     ` Philippe Gerum
2007-06-29 15:56                       ` Gilles Chanteperdrix
2007-06-29 15:52                     ` Jan Kiszka
2007-07-08 10:11                 ` Jan Kiszka
2007-07-09  8:49                   ` Daniel Simon
2007-07-11 13:59                   ` Daniel Simon
2007-07-11 14:30                     ` Jan Kiszka
2007-07-11 15:35                       ` Daniel Simon
2007-07-11 15:56                         ` Jan Kiszka
2007-07-11 16:55                           ` Daniel Simon
2007-07-11 21:20                             ` Jan Kiszka
2007-07-12  9:30                               ` Daniel Simon
2007-07-12 11:02                                 ` Jan Kiszka
2007-07-16 16:19                                   ` Daniel Simon
     [not found]   ` <1753.194.254.210.7.1181246882.squirrel@domain.hid>
2007-06-08 15:19     ` [Xenomai-help] real time task disapears... memory problem ? Jan Kiszka
2007-06-09 16:06       ` desvages
2007-06-09 17:10         ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46693B6B.1010201@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=Daniel.Simon@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.