[dtrace-discuss] track program time - need some guidelines

James Litchfield
2009-07-12T17:28:43Z

It goes back to what problem is being solved.

A) ptime requires that it start the app. It can''t
     attach to a running app. It aggregates all the
     data and does not offer a per-lwp breakdown.
     Given the mechanisms it uses, that''s all it can do.
     If that''s adequate then the problem is solved.

B) adding up prstat -Lm values seems fairly clunky
     but it would work and I''m sure that one could script
     something up to do the work.

C) extended accounting says it supports ''mstate'' but
     the demo program (/usr/demo/libexacct/exdump.c)
     doesn''t emit it.

     This is all that comes out...

     100b     cpu-user-sec                     0
     100c     cpu-user-nsec                    3585639
     100d     cpu-sys-sec                      0
     100e     cpu-sys-nsec                     4956882

     Reviewing /usr/include/sys/exacct_catalog.h would
     indicate that, if the information is indeed collected, it is
     not obviously extractable.

D) Actually a /proc reader wouldn''t work as the needed
     information is not available in any of the structures.
     You''d need a kmem reader to get the info which is
     definitely on the tricky side.

As a note to ''tester'', microstate accounting is not tied to
ticks of statistical profiling. The kernel tracks the time
that an LWP spends in each state it''s in. It''s far more
accurate than tick based accounting.

Jim
----


Jim Mauro wrote:
>
> So......why is prstat with microstates not sufficient?
> Observing your app with;
> prstat -Lcmp <PID> 1 10 > prstat.out
>
> Will give you statistics collected at 1 second intervals for
> 10 seconds. You can do the math if you really need to
> get down to clock ticks (roughly).
>
> Chad''s modified ptime will give you time spent in each microstate.
>
> Also, as per Marty''s suggestion, the Studio Analyzer, which is
free,
> can do high resolution profiling.
>
> Writing C code to extract data from /proc, which would work, is like
> spending a lot of time and tools removing a car engine completely
> from the top, just so you can change the oil filter, when all you had
> to do was slide under the car to do it.
>
> Unless you''re goal is skill development or this is an academic
exercise,
> I''d love to know what you''re trying to accomplish - what
problem
> you''re trying to solve. On a modern microprocessor with
> sub-nanosecond clocking, do you really need clock-tick level
> accounting?
>
> Thanks,
> /jim
>
>
> tester wrote:
>> Thanks Jim.M and  thanks Jim.L. Sure, I can use prstat and
>> post-process. I am not sure if I can get a accurate profile of the
>> app. If I can go back to my previous example and assume an
>> multi-threaded app running for 100 clock ticks, I would like to have
>> a break up and say
>> usr:20ticks,sys:10,wait1:20,wait2:20,wait3:20,sleep:10. Units of time
>> can be anything meaningful. Basically, a much more accurate answer
>> for where my app spend it''s time than what the traditional
tools offer.
>>
>> I will explore extended accounting and Jim.L suggestion of using
>> /proc. I have limitation''s with my C programming skills.
>> Thanks
>>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org