From: Maynard J. <may...@us...> - 2009-08-10 12:49:13
|
Ian jonhson wrote: > Hi again, > > I have installed oprofile in my machine sucessully. And I have > tried to catch samples from my OS. > > Following to oprofile manual, > > # opcontrol --event=INST_RETIRED_ANY_P:8000 // <-- set event > # opcontrol --vmlinux=/boot/2.6.0/vmlinux > # opcontrol --start-daemon > # opcontrol --start > # /tmp/mycount2 // <--- my simple execuable > # opcontrol --stop > # # opreport > /tmp/myoprofile_mycount // <-- output the > > Then, I cated the /tmp/myoprofile_mycount and got: > > ---------------- dump of screen ------------------ > CPU: Core 2, speed 1200 MHz (estimated) > Counted INST_RETIRED_ANY_P events (number of instructions retired) > with a unit mask of 0x00 (No unit mask) count 8000 > INST_RETIRED_A...| > samples| %| > ------------------ > 3750992 80.4060 mycount2 > 641079 13.7421 vmlinux > 153826 3.2974 oprofiled > 61083 1.3094 libc-2.5.so > 12258 0.2628 bash > 10206 0.2188 libavahi-common.so.3.4.3 > 6568 0.1408 gmetad > ... > ------------------------------------------------------- > > So, I can get the total running instructions of whole system during > the running of mycounts: > > total_instruction_of_whole_OS = 3750992 / 0.804 > > As for the elapsed time, I don't know how to get should be more accurate. > Because I want to use the MIPS value to evaluate environment quality, it > should not use the CPU parameter (1200 MHz) in my calculation. So, > what should I do to guess the time interval between --start and --stop? > If I want to let oprofile to do sampling per 5 seconds, should I restart > it in each 5 seconds (by opcontrol --start and opcontrol --stop again and > again)? I don't know what you're trying to achieve, but if you don't mind the perturbation that would occur in your system with the restarting of oprofile every 5 seconds (and, presumably, the generation of a report every 5 seconds), then go ahead and do it this way. But don't forget to do 'opcontrol --reset' before --start, unless you want cumulative profile data. > > Further, there are something needed to make clear: > > a) the event seems to be hard to clear when oprofile daemon is running. > when I re-define a new event, the event just is added to oprofile and can > not replace previous one. Is there any command to clear previous events? You need the shutdown the daemon and restart it for it to pick up new parameters. So instead of doing 'opcontrol --stop', do 'opcontrol --shutdown', which does an implicit stop + daemon shutdown. > > b) In my DELL 360 with Intel Core2, there are two events explained with > retired instructions: INST_RETIRED_ANY_P and INST_RETIRED. what > is different between them? But when I set INST_RETIRED to oprofile, > I got the statics of INST_RETIRED_ANY_P. In other words, both events > point to same event name internal (I test them by setting different count number > in oprofile and the opreport shows they are same one). I don't speak Intel, but if you do 'ophelp', you should see a reference (at the beginning of the output) to the Intel manual that should provide more details about hardware events. > > > c) In parameter definition: --event=name:count:unitmask:kernel:user, > what is exact meaning of "count"? does it mean all profiled data will > be cleared up when count is full? No, this is the sampling interval -- e.g., for '--event=INST_RETIRED_ANY_P:8000', a sample is taken every 8000 INST_RETIRED_ANY_P events that are counted. Profile data is not cleared except for when you do 'opcontrol --reset' (which should generally be done every time before you start profiling so you're not mixing in old profile data with a new profile run. -Maynard > If so, whether does it affect report result? > > > Thanks, > > Ian > >> Assuming that you start up oprofile right before running the experiment and shut >> it down right after the experiment, you could estimate the total number of >> events from the opreport data. The basic opreport give a count and the >> percentage of the total count for each executable. >> >> total_events = count_per_sample * (sample_count/percentage) >> >> Using data from >> http://www.redhat.com/magazine/012oct05/features/oprofile/overall.txt >> in http://www.redhat.com/magazine/012oct05/features/oprofile/ >> >> CPU: PIII, speed 860.959 MHz (estimated) >> Counted CPU_CLK_UNHALTED events (clocks processor is not halted) with a unit >> mask of 0x00 (No unit mask) count 860000 >> CPU_CLK_UNHALT...| >> samples| %| >> ------------------ >> 3233425 50.5528 /usr/libexec/gcc/i386-redhat-linux/4.0.1/cc1plus >> >> >> total_events = 860000 * (3233425/0.5055) = 5.50e12 clock cycles >> > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list |