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: Monitoring mm->nr_ptes


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.


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