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 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
