Philippe Gerum wrote: > On Thu, 2006-07-06 at 17:09 +0200, Jan Kiszka wrote: >>> We could do that from the current loop below, given that the >>> accumulation routine is changed to use thread->sched implicitely. >> The idea is avoid adding even further load to the nklock-protected loop. >> And we only update the current thread, not each and every. >> > > Yes, but why? I mean, accumulated time so far remains significant even > for non-running threads.
Update must only happen for the currently running thread on each cpu, otherwise you skew the stats up. But looking at the whole code in stat_seq_open() again, I now wonder if that whole routine isn't a) fragile on task removal and b) still poorly scaling. The thread name is only copied by reference, a disappearing instance my cause troubles on printing it. And, instead of holding the lock all the time, shouldn't we better 1. pick some element from the queue and mark it somehow in-use under lock 2. print or copy the entry 3. reacquire the lock to proceed to the next one - after checking if that element happened to be removed from the queue meanwhile (in that case we could abort the output or try to resync) I'm worrying about a potential nice xeno-top tool polling the stats at high frequency and causing unexpected jitters if there are a significant number tasks registered (think of passive shadows we may create automatically in the future!). Jan
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core