Re: [Xenomai-core] measuring tasks execution time

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

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

Daniel Simon wrote:
> On Wed, 27 Jun 2007 13:56:04 +0200
> Jan Kiszka <jan.kiszka@domain.hid> wrote:
> 
>>> On Mon, 25 Jun 2007 18:55:45 +0200
>>> Jan Kiszka <jan.kiszka@domain.hid> 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.

Jan


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