I know some ...

>-----Ursprüngliche Nachricht-----
>Von: Colin Burgess [mailto:community-noreply@qnx.com] 
>Gesendet: Freitag, 7. November 2008 17:44
>An: ostech-core_os
>Betreff: Re: AW: How to know that thread is preempted?
>
>No.  I can't think of a way to determine that you have been 
>preempted on a non instrumented kernel.
>
>But who would be foolish enough to run that? ;-)
>
>Colin
>
>Elena Laskavaia wrote:
>> Is it related to tracelogger? Would it work on 
>non-instrumented kernel?
>> 
>> Colin Burgess wrote:
>> 
>>> Elena you will have to attach to the THRUNNING event handler I think
>>>
>>> H
>> 
>> _______________________________________________
>> OSTech
>> http://community.qnx.com/sf/go/post16216
>> 
>
>--
>cburgess@qnx.com
>
>_______________________________________________
>OSTech
>http://community.qnx.com/sf/go/post16219
>
> 
 
*******************************************
Harman Becker Automotive Systems GmbH
Management Board: Dr. Klaus Blickle (Chairman), Dr. Udo Hüls, Michael Mauser, Regis Baudot
Chairman of the Supervisory Board: Ansgar Rempp | Domicile: Karlsbad | 
Local Court Mannheim: Register No. 361395

 
*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat 
sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail
. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have 
received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, 
disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************

I think it's about the profiling that's done using -finstrument-functions *without* traclogger
and for this case we need the log file.

I think you don't need additional events for the tracelogger functions profiling, you already have all the events
you need to do the accounting on IDE side.

I don't like the way I work below, because it's a YATL (yet another tracelogger logger)
so why not use tracelogger instead with some filters set.

or .... dtrace

/hp


>-----Ursprüngliche Nachricht-----
>Von: Colin Burgess [mailto:community-noreply@qnx.com] 
>Gesendet: Freitag, 7. November 2008 17:54
>An: ostech-core_os
>Betreff: Re: AW: AW: How to know that thread is preempted?
>
>Elena was not producing a log, she was measuring time spent.
>
>The main thing that would have to change is that she would 
>have to specify the times to count in the event handler user data.
>
>The event handler would maintain the time that we were READY 
>so it could be subtracted from the elapsed ClockCycles() time.
>
>The way you are working below it would be better to use the 
>SYSTEM function enter/exit codes like she does in her kernel 
>instrumentation based profiler.  But she apparentely needs to 
>add THRUNNING events into that too.
>
>Colin
>
>Hans-Peter Reichert wrote:
>> for the event filter solution:
>> how do you handle nested preemtions?
>> and how can you quantify the preemptions?
>> you only can do interrupt restricted things inside your 
>event filter/handler.
>> So in best case you do something like this
>> 
>> call void foo()
>> log f_enter in file.ptrace
>> ... do some work
>> yield to thread X, event handler is called log f_yield (pid, tid) in 
>> file.ptrace ... do some work yield to thread Y, event handler is 
>> called log f_yield (pid, tid) in file.ptrace yield back to original 
>> thread, event handler is called ... do more work log f_exit in 
>> file.ptrace
>> 
>> but this could only be done if the used file.ptrace is 
>accessable inside the dynamic event handler functions.
>> which is not the fact, cause it's a normal file.
>> So making this file accessable through kernel memory would make it.
>> 
>> /hp
>> 
>> 
>>> -----Ursprüngliche Nachricht-----
>>> Von: Colin Burgess [mailto:community-noreply@qnx.com]
>>> Gesendet: Freitag, 7. November 2008 17:23
>>> An: ostech-core_os
>>> Betreff: Re: AW: How to know that thread is preempted?
>>>
>>> Yes, but ClockTime doesn't give you the same resolution as
>>> ClockCycles() - since it uses the OS accounting which is coarse 
>>> grained.
>>>
>>> Elena you will have to attach to the THRUNNING event handler I think
>>>
>>> Hans-Peter Reichert wrote:
>>>> we do it like this for our self made (sometimes sneaky) tools:
>>>>
>>>> myClockId = ClockId(getpid(), pthread_self()); // check the id
>>>>
>>>> rc = ClockTime(myClockId, 0, &timeStart); //check rc
>>>>
>>>>   ... do the stuff to measure ...
>>>>
>>>>
>>>> rc = ClockTime(myClockId, 0, &timeEnd); //check rc
>>>>
>>>> cpuNanos = (timeEnd - timeStart);
>>>>
>>>>
>>>> _______________________________________________
>>>> OSTech
>>>> http://community.qnx.com/sf/go/post16211
>>>>
>>> --
>>> cburgess@qnx.com
>>>
>>> _______________________________________________
>>> OSTech
>>> http://community.qnx.com/sf/go/post16212
>>>
>>>
>>  
>>...

Thanks all for you suggestions!

If we go into details there are two scenarios:
  - one is using instrumented kernel - right now we inject function enter/exit and
I think I can extract preemption event from the same log already.

- second is not using instrumented kernel and using "file" to log time spent (it is buffered, so it does not have to be 
called from traceevent handler),
in this case I think I should use ClockTime as suggested earlier.



Colin Burgess wrote:
> Elena was not producing a log, she was measuring time spent.
> 
> The main thing that would have to change is that she would have to specify the times to count
> in the event handler user data.
> 
> The event handler would maintain the time that we were READY so it could be subtracted from the elapsed ClockCycles() 
time.
> 
> The way you are working below it would be better to use the SYSTEM function enter/exit codes like she does in her 
kernel
> instrumentation based profiler.  But she apparentely needs to add THRUNNING events into that too.
> 
> Colin
> 
> Hans-Peter Reichert wrote:
>> for the event filter solution:
>> how do you handle nested preemtions?
>> and how can you quantify the preemptions?
>> you only can do interrupt restricted things inside your event filter/handler.
>> So in best case you do something like this
>>
>> call void foo()
>> log f_enter in file.ptrace
>> ... do some work
>> yield to thread X, event handler is called
>> log f_yield (pid, tid) in file.ptrace
>> ... do some work
>> yield to thread Y, event handler is called
>> log f_yield (pid, tid) in file.ptrace
>> yield back to original thread, event handler is called
>> ... do more work
>> log f_exit in file.ptrace
>>
>> but this could only be done if the used file.ptrace is accessable inside the dynamic event handler functions.
>> which is not the fact, cause it's a normal file.
>> So making this file accessable through kernel memory would make it.
>>
>> /hp
>>
>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Colin Burgess [mailto:community-noreply@qnx.com] 
>>> Gesendet: Freitag, 7. November 2008 17:23
>>> An: ostech-core_os
>>> Betreff: Re: AW: How to know that thread is preempted?
>>>
>>> Yes, but ClockTime doesn't give you the same resolution as 
>>> ClockCycles() - since it uses the OS accounting which is 
>>> coarse grained.
>>>
>>> Elena you will have to attach to the THRUNNING event handler I think
>>>
>>> Hans-Peter Reichert wrote:
>>>> we do it like this for our self made (sometimes sneaky) tools:
>>>>
>>>> myClockId = ClockId(getpid(), pthread_self()); // check the id
>>>>
>>>> rc = ClockTime(myClockId, 0, &timeStart); //check rc
>>>>
>>>>   ... do the stuff to measure ...
>>>>
>>>>
>>>> rc = ClockTime(myClockId, 0, &timeEnd); //check rc
>>>>
>>>> cpuNanos = (timeEnd - timeStart);
>>>>
>>>>
>>>> _______________________________________________
>>>> OSTech
>>>> http://community.qnx.com/sf/go/post16211
>>>>
>>> --
>>> cburgess@qnx.com
>>>
>>> _______________________________________________
>>> OSTech
>>> http://community.qnx.com/sf/go/post16212
>>>
>>>
>>  
>> *******************************************
>> Harman Becker Automotive Systems GmbH
>> Management Board: Dr. Klaus Blickle (Chairman), Dr. Udo Hüls, Michael Mauser, Regis Baudot
>> Chairman of the Supervisory...