Hi,
Abhishek Bhattacharjee wrote:
Hi Gavin
Thanks for pointing out the TRAPTRACE mechanism. It so happens at the
experiment that TJ and I want to run (we are working together) involves
profiling the virtual and physical addresses prompting TLB misses through the
execution of a given application. It looks like the TRAPTRACE facility allows
only 32 traps to be profiled and I'm assuming that there is some sort of cap on
how high this number can go up to.
TRAPTRACE allocates some physically contiguous memory for each cpu,
so that we can write out records using physical memory accesses
(for obvious reasons during TLB miss traps). It also sets
up a virtual mappings of the traptrace buffer, and it is
through those that we can retrieve records so as to use
them in ::trace etc.
There is no profiling as such with traptrace - each software
trap handler (or nearly all of them) simply writes out
a record recording the trap type and some additional info
to the next available record in the buffer, wrapping around
when we fill the buffer.
Ideally, we were hoping to have a buffer (storing TLB miss info) accessible from the clock() routine that could be printed periodically to the console. We were hoping that we could access this buffer from within the TLB miss handlers to put all the TLB miss information in the buffer. However, we are unclear as to whether this is possible because the buffer initialized in the clock() routine would be allocated in virtual memory. Therefore, passing a pointer to this buffer to the TLB handler would not be helpful (since it is our understanding that the TLB handlers only access physical memory).
Is there an easy way around this somehow?
No chance! You could write something to periodically empty the buffers
but it wouldn't be trivial.
Back when Bryan Cantrill wrote trapstat he also had a utility
which I think went by the name of 'atrace' (application trace).
This was a standalone utility, never integrated into Solaris.
It kept the hardware TLB empty on sun4u/sparc machines.
When an access traps we allow the handler to fill
the TLB with that one translation, and force a further
trap to occur after allowing just the originally trapping
access to execute; in the followup trap we invalidate
the translation in the TLB so that it will trap again
if accessed. This produced a "very fast single stepping,
or very slow execution" trace of TLB accesses.
The presentation he gave at the time is still marked
for internal use only, but you may want to flesh the
idea out again for your purposes.
Gavin
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
