Daniel Simon 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.

> 
>> Instead, you establish quite some new calculations that break
>> the existing API (the switch date is given via "start" - which was
>> misnamed so far, I just changed it to "date") 
> 
> ok, better fit the behaviour.
> I should better work from the last svn version?

SVN trunk would be best, indeed.

> 
>> and increase the runtime
>> overhead in the hotpath. Why? All the information you should need is
>> already there, it just has to be saved from being vaporised when the
>> user dumps /proc/xenomai/stat.
>>
>>>     (sched)->last_account_switch = start; \
>>>  } while (0)
>>>    
>> 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 "xnstat_runtime_t last;" to xnthread_t::stat. On readout
>> for /proc output, 
> Where is this done? I've found one place in module::stat_seq_open where total 
> is
> reset to 0, is it the only one? 

That's one spot, the other is xnpod_migrate_thread()
(xnstat_runtime_reset_stats()) IIRC.

> In fact I don't have a clear picture of the stat
> process and what it is assumed to do (and thus did not want to break 
> something!)

Stat generation happens based on services that are provided by
nucleus/stat.h, stat dumping is concentrated in modules.c, namely
stat_seq_open. Using the cross reference [1] can help if you want to
verify this on your own.

>> do the stats now like "account-last" and then move
>> 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?
> 
>> Thanks for working on this!
> I'll try to find enough time by the end of this week to improve this...
> 
>       Daniel
> 

Looking forward.

Jan

[1] http://www.rts.uni-hannover.de/xenomai/lxr/source/?v=SVN-trunk

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to