This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tracking vm activity


On 4/24/07, William Cohen <wcohen@redhat.com> wrote:
Hi,

I am playing around with getting information about page faults and I noticed
that there is a probe alias for the entry for the pagefault code. However, there
is no matching probe point for the return. It is useful to look at the return
value to determine what kind of page fault occurred (major or minor). The
attached patch provides a similar probe point for the return point. any comments
on the patch?

This would be useful for the following senario. A probe on vm.pagefault could
get the address and a probe on vm.pagefault.return could get information how it
was handled. The analysis could then do things like which addresses cause major
page faults (real disk accesses). One could write out a log of the major page
faults (and the mmap operations) and track which files caused the page faults.
Probably don't want to walk through the mm structures when taking a page fault
to determine which file it came from.


Hi Will,


I found this idea interesting. However, what do you think if the
machine is SMP, or kernel is preemptive capable?

Just imagine a scenario like this with 2 kernel threads A and B:
- A causes page fault, then enters page fault handler (1)
- B preempts A, causes fault, then enters page fault handler  (2)
- A exits page fault handler (3)
- B exits page fault handler (4)

In this case, you get the exit value at (3), but it is not relevant to
the parameters collected in the above step (2).

I cannot figure out how to correlate "enter" and "exit" function
events in SMP or preemptive case.

Any idea?

Thanks,
Jun


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]