Daniel Simon wrote:
> On Wed, 27 Jun 2007 13:56:04 +0200
> Jan Kiszka <[EMAIL PROTECTED]> wrote:
>>> On Mon, 25 Jun 2007 18:55:45 +0200
>>> Jan Kiszka <[EMAIL PROTECTED]> wrote:
>>>> My idea was to keep a persistent version the existing xnstat_runtime_t
>>>> instance in xnthread (and later on also xnintr). That one shall not be
>>>> reset on readout via /proc.
>>> Is it necessary to keep also the reset one?
>> Yep, at least virtually (as in my proposal): We are dumping CPU share
>> percentages in /proc, and those need to be calculated over the same
>> measurement period. Thus we restart the measurement each time the user
>> reads the stats.
>>>> Let's try it like this: Change Xenomai so that it leaves the existing
>>>> xnthread_t::stat.account untouched when it reads /proc. Rather add
>>>> something like " last;" to xnthread_t::stat. On readout
>>>> for /proc output, 
>> That's one spot, the other is xnpod_migrate_thread()
>> (xnstat_runtime_reset_stats()) IIRC.
> ok, i've found only these two reset points.
> the account structure is also partially touched by  xnstat_runtime_finalize()
> in pod.c, I don't understand when and why...

xnstat_runtime_finalize is called when a task passes away, i.e. you
wouldn't be able to retrieve it's stats later on anyway.

>>>> account into last. For your task exectime, you can then read
>>>> xnthread_t::stat.account directly, because it will always reflect the
>>>> full task history. Would't this work better?
>> Jan
> please find attached a new patch following these ideas:
>  (patch against svn trunk Revision: 2672) 
> account is now persistent, its "start" field is the last_switch time, and the
> new xnstat_runtime_t "lastperiod" handles the past values necessary to compute
> the runtime values plot at snapshot time.
> from a few trials, it seems that /proc/xenomai/stat still behaves normally 
> (i.e.
> like in the original version where the first reading of stat does gives 
> nothing
> for the tasks runtime?)

The first dump is always bogus as the task set changed since the
previous measurement date (here: Xenomai start-up time).

> exectime returns likely values when a task is measured by another one, but 
> self
> measurement (with the NULL task calling parameter in rt_task_inquire) sometime
> provides incoherent values (e.g. returns the period rather than the exectime,
> or returns non-monotonic exectime values...). 
> I could not manage to fix this bug upto now. 

I think I already see one, though it doesn't explain all your observed
behaviour to me:

> --- xenomai-orig/ksrc/skins/native/task.c     2007-06-28 10:20:17.000000000 
> +0200
> +++ xenomai/ksrc/skins/native/task.c  2007-06-28 17:20:29.000000000 +0200
> @@ -1144,7 +1144,10 @@
>       info->cprio = xnthread_current_priority(&task->thread_base);
>       info->status = xnthread_state_flags(&task->thread_base);
>       info->relpoint = xntimer_get_date(&task->thread_base.ptimer);
> -
> +     if(task == xeno_current_task())
> +       info->exectime = xnthread_get_exectime(&task->thread_base) + 
> (xnstat_runtime_now() - xnthread_get_lastswitch(&task->thread_base));
> +     else 
> +       info->exectime = xnthread_get_exectime(&task->thread_base);

Exectime is only updated on task switches. So you are not obtaining the true 
value when requesting your own data. Use the same formula for both cases.

> And unfortunately i'll be away and probably far from any xenomai-capable
> machine next week...

OK. I'll try to look into this in the meantime. But I think it should be no 
problem to merge a final version even after the approaching 2.4-rc1, the patch 
is yet fairly confined.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to