James Litchfield wrote:
Too bad vminfo doesn't provide addresses but this may serve as a
starting point...
#pragma D option quiet
/*
* For i86pc systems!
*/
#include <sys/types.h>
#include <ia32/sys/trap.h>
#include <ia32/sys/psw.h>
:::trap:entry
/pid == $target && USERMODE(args[0]->r_cs) != 0 && args[0]->r_trapno
== T_PGFLT/
{
printf("0x%p\n", args[1]);
}
dtrace -C -s trap.d -c "some command and args"
Jim
----
Joel Reymont wrote:
Can someone suggest a DTrace provider for tracking virtual memory
pageins and pageouts in a certain memory range?
The memory range would be one established by mmap and I'm tracking
memory access patterns within Firefox. Various dynamic libraries that
Firefox uses are mmap-ed by the dynamic linker and I capture the
address and range of each mapping.
What I would like to do now is see what order the pages in each
library range are being pulled in from disk. Eventually, I'd like to
optimize the order of symbols in each shared library to make access
sequential as possible.
Any suggestions on how to track page faults in a memory range?
Tracking page faults is pretty straight forward. Tracking pageins and
pageouts is more
problematic. You can use the fbt provider to track page faults. This
should work on
both x86 and sparc.
pagefaultrange.d
#!/usr/sbin/dtrace -s
pagefault:entry
/execname == "firefox-bin" &&
$1 <= arg0 && arg0 <= $2/
{
printf("firefox fault on addr %a, fault type = %x\n", arg0, arg1);
}
To run:
# ./pagefaultrange.d 0 0xffffffff
This will track pagefaults in all addresses in (32-bit) firefox-bin.
If arg1 is 0, the fault address is not valid (and a page may need to be
allocated
or reclaimed), and if arg1 is 1, it is a protection (copy-on-write,
perhaps) fault.
The problem with tracking pageins is that a pagefault may result in
more than 1 page being paged in. The problem with tracking pageouts
is that there is no direct link from the page being paged out back to the
process(es) using the page. You would have to keep track of the pages as
they are brought in to see when any of those pages are paged out. (Note
that this does not mean it can't be done, but it is more work).
max
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
