Re: [Xenomai-core] measuring tasks execution time
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? 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? 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? 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!) 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 -- Daniel SIMONProjet NeCS INRIA Rhone-Alpes Inovallee, 655 avenue de l'Europe, Montbonnot 38 334 Saint Ismier Cedex France [EMAIL PROTECTED] Phone:(33)476615328 Fax:(33)476615252 http://necs.inrialpes.fr/people/simon/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Monotonic, realtime, and other timers
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: IMO, the only advantage of having absolute timers is to be able to apply the posix scheme. So, if I followed correctly your discussion, what we need is: - an XNTBISOL flag with a service xntbase_isol which set this flag and unshare the target timebase if it is shared (IOW, if aperiodic) - the service xntbase_adjust_time to walk all the absolute timers of the non isolated timebases and adjust their expiry date or play their handler the posix way. Two questions came up here regarding item #2: - Shouldn't we also adjust the non-monotonic timers of an isolated base if it asks for wallclock tuning? I think so. - We don't have a service to walk the list of all pending timers, do we? As that touches all of our timer queue variants and I'm not familiar with their details (except for plain lists...), I would welcome any support on this. I am afraid for other things than lists, we will have to define an xntimerq_iterator which holds a little bit more information than just a pointer to a holder. So we would have to increase the size of each xntimer_t object? Argh. Sounds a bit like it's worth to have a closer look at some two timer lists, one with adjustable offset-approach... No, I was thinking about defining a new type xntimerq_iterator, whose sole purpose would be to hold the state of an iteration. In fact, we only need this in the hashed case, binary heap holders already contain enough information. OK, if that will not have negative impact on existing code, so much the better. Meanwhile I uploaded my current patch stack to http://www.rts.uni-hannover.de/rtaddon/patches/xenomai. I'm going to comment on detail aspects later. Just so much: it /should/ be finished except for the yet empty placeholder re-adjust-timers.patch. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] measuring tasks execution time
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
