This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Monitoring mm->nr_ptes
- From: Josh Stone <jistone at redhat dot com>
- To: "Paddie O'Brien" <paddieobrien at gmail dot com>, systemtap <systemtap at sourceware dot org>
- Date: Tue, 6 Sep 2016 17:34:36 -0700
- Subject: Re: Monitoring mm->nr_ptes
- Authentication-results: sourceware.org; auth=none
- References: <CAOK12DZtZSMA9F_XwRpNZWHAe984mF5DeJyCh+yWyGn1aCEsig@mail.gmail.com>
On 09/06/2016 02:42 PM, Paddie O'Brien wrote:
> I'm trying to monitor changes to mm->nr_ptes. I'd like to probe
> __pte_alloc in mm/memory.c but systemtap cannot see it. Why is that?
This is captured by a very broad entry in our blacklist, ".*_pte_.*".
That was added with little explanation in 2fd5495a269c9. The only
reference is to a RHBZ bug that's unfortunately marked private:
https://bugzilla.redhat.com/show_bug.cgi?id=580943
Perhaps we should revisit that one and see if it can be a bit tighter.
In the meantime, you can override the blacklist with "-g" guru mode.
> Do I have to identify and probe all functions where a change is made
> to mm->nr_ptes or can I watch for changes to mm->nr_ptes? I looked at
> the watchpoint systemtap examples but they seem to apply only to
> global symbols.
I don't know an easy way to do this for such a dynamic symbol, sorry.
Perhaps you could use something like:
git grep -F -- '->nr_ptes'
in the kernel tree of your choice, then script those into probes like:
probe kernel.statement("*@mm/hugememory.c:533"),
kernel.statement("*@mm/memory.c:410")
{
/* print some data, but what? */
}
Figuring out what to print in an automated way seems hard.
The list I get from grepping isn't very long though, so perhaps it won't
be so bad to manually build up a set of probes in this case.