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