I think that is pretty highly dependent on your workload. If the program is very short then running then most of the work is going to be done in creating a new process and shutting down the process and going back to the shell. Also initially the kernel will probably be doing all kinds of virtual memory operations as the program starts up. Also perhaps the code makes lots of system calls....?
Though you're right 0.16% sounds pretty small. Can you just instrument the code in the middle with ptlcall_switch_to_native() and ptlcall_kill() to just get a piece of code of interest? That way you might see a higher percentage of user space activity ... On Tue, Jan 11, 2011 at 1:21 AM, sunil shah <[email protected]>wrote: > Hi, > so it means only 0.16% of instruction are for test application and rest for > kernel and background work. > Is not this quite unbalanced? > > Thanks & Regards > Sunil shah > > > > On Tue, Jan 11, 2011 at 1:24 PM, Furat Afram <[email protected]>wrote: > >> Hi >> Since MARSS is a full system simulator it simulates both kernel and user >> space instructions , the 0Xffffffff81391884 rips are a kernel >> instructions . >> -Furat >> >> On Tue, Jan 11, 2011 at 12:06 AM, sunil shah <[email protected]>wrote: >> >>> Hello Avadh, >>> >>> Thank you for the help. >>> >>> >>> >>> I want to get the virtual address trace of x86 instruction executed. >>>>> >>>> >>>> >>> By default Marss provides a way to generate an execution trace. In >>>> 'ptlsim.h' file, un-comment the '#define TRACE_RIP' and recompile. This >>>> will enable capturing trace of executed instructions in file >>>> 'ptl_rip_trace'. Note: If you run for long time this fill will eat up all >>>> hard-disk space. >>>> >>> >>> Enabling the TRACE_RIP will produce rip of all the uop. One x86 >>> instruction might be broken down into multiple uop. So, just to get only one >>> commit rip per x86 instruction I tried to obtain the rip of committed >>> instruction from *ReorderBufferEntry::commit() *instead of >>> *ThreadContext:commit(). >>> *I verified both will generate the same sequence of rip's expect with >>> TRACE_RIP enable, it will have as many entry of a rip as number of uop for >>> the x86 instruction. >>> >>>> >>>> I tried using in *ReorderBufferEntry::commit()* function field, * >>>>> uop.rip.rip* field is giving some address but the obtained address is >>>>> not same at the virtual address of instruction which I obtained by using >>>>> objdump to disassemble the executable I am running. >>>>> >>>>> That is interesting. At what point are you switching from emulation to >>>> simulation? If you are using 'start_sim' tool then it takes about 1 million >>>> instructions to complete and start the next process. >>>> >>> >>> Yes, I am using start_sim to switch from emulation to simulation. >>> >>>> >>>> Also take a look at this python script ( >>>> https://github.com/downloads/avadhpatel/marss/trace_to_func.py) that >>>> helps in mapping RIP address to function of your benchmark/application. >>>> >>> >>> RIP address is matched against the virtual address's of function obtained >>> by objdump of executable. But the rip obtained are not always in the range >>> of virtual addresses of function obtained by objdump. For instance mostly >>> virtual address are in the range of 0X40xxxx but rip obtained are quite >>> high values like 0X00007fe91323c3b7 or 0Xffffffff81391884 or so. Only >>> *0.15%* of address are in small address range rest are all high address >>> value. >>> >>> So this addresses belongs to which function or program? >>> Why there is no matching rip value to the virtual address of executable.? >>> I am not sure, is there any offset or some re-mapping of testbench >>> application into PTLSim memory map to some specific memory region? >>> >>> I am trying to generate basic block trace. What I am aiming to obtain is >>> all executed instruction virtual address. And offline/ online I will convert >>> it to basic block trace. >>> >>> >>> Sorry for such a long email. >>> >>> Thanks & Regards >>> Sunil Shah >>> >>> >>> >>> >>> >>> >>>> - Avadh >>>> >>>>> Any help will be highly appreciated. >>>>> Thanks in anticipation >>>>> >>>>> Regards >>>>> Sunil Shah >>>>> School of Computing >>>>> NUS >>>>> Singapore >>>>> >>>>> >>>>> _______________________________________________ >>>>> http://www.marss86.org >>>>> Marss86-Devel mailing list >>>>> [email protected] >>>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> http://www.marss86.org >>> Marss86-Devel mailing list >>> [email protected] >>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >>> >>> >> > > _______________________________________________ > http://www.marss86.org > Marss86-Devel mailing list > [email protected] > https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel > >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
