From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [Xenomai-core] [RFC, PATCH] per-thread exec-time stats From: Philippe Gerum In-Reply-To: <17582.13798.272437.979081@domain.hid> References: <44ACF5FA.2050205@domain.hid> <1152196379.4978.74.camel@domain.hid> <17581.41221.527736.416354@domain.hid> <1152258866.5017.4.camel@domain.hid> <17582.13798.272437.979081@domain.hid> Content-Type: text/plain Date: Fri, 07 Jul 2006 15:23:30 +0200 Message-Id: <1152278610.5035.12.camel@domain.hid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: rpm@xenomai.org List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: Jan Kiszka , xenomai-core On Fri, 2006-07-07 at 12:22 +0200, Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > On Fri, 2006-07-07 at 01:47 +0200, Gilles Chanteperdrix wrote: > > > Philippe Gerum wrote: > > > > > +#ifdef CONFIG_XENO_OPT_STATS > > > > > +static inline void xnpod_acc_exec_time(xnsched_t *sched, > > > > > + xnthread_t *threadout) > > > > > +{ > > > > > + xnticks_t now = xntimer_get_rawclock(); > > > > > + threadout->stat.exec_time += now - sched->last_csw; > > > > > + sched->last_csw = now; > > > > > +} > > > > > > > > It would be better to only pass the thread pointer, then use the > > > > thread->sched member. This would clearly explain the relationship > > > > between both, and prevent any bugous attempt at mixing things. > > > > > > Beware, when xnpod_schedule is called from within > > > xnpod_migrate_thread(), the sched pointer of the switched out thread is > > > the one of the destination cpu. So, passing the sched and threadout > > > pointers to xnpod_acc_exec_time is safer. > > > > Nope, the nklock is held by the migrating thread all along until the > > switch has actually occured. > > xnpod_acc_exec_time() is called from within xnpod_schedule() that is > called from within xnpod_migrate_thread() at a time where > threadout->sched is the wrong pointer. Gasp. Unfortunately, we are trapped by an exception case, and I don't see any better approach. > -- Philippe.