Re: [Xenomai-core] [RFC, PATCH] per-thread exec-time stats

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]