Fwd: proc_mem modification to allow use in timer probes

[Charley Wang <chwang at redhat dot com>]

As requested by Mark, moving discussion to SystemTap mailing list.
Based on brief video below that uses proc_mem in a timer probe to check
memory usage of a user process (based on a SystemTap example script)
http://chwang.fedorapeople.org/cpu_usage.ogg

I tried to 'save' the location of the mm_struct for the user process.

I made a mm_struct* in proc_mem, and then had the function _stp_proc_mm() 
return mm if mm != NULL. Calling a setup function stores current->mm.

Seems like it makes some (dangerous?) assumptions about the validity
of the stored mm_struct. When I ran controlled tests with malloc and free
it seemed to report memory usage properly. The saved mm_struct* appears
to update without needing additional calls to the setup function, possibly
because of the aforementioned assumptions :(

When I attempt to use proc_mem functions in their current form I seem to
sometimes pick up the memory usage of processes I'm not interested in:
http://chwang.fedorapeople.org/systemtap-proc_mem-without-setup.png

Probably it would be better to try and get the 'current' for a target pid 
than to store mm_struct like this... I'd be happy to investigate further
and post a bug, if you like.



Here's the brutish hack to proc_mem.stp I used when making the graphs:
proc_mem.stp:

struct mm_struct *mm = NULL;
  static struct mm_struct *_stp_proc_mm(void)
  {
    if (mm != NULL) {
      return mm;
    }
    if (current->flags & (_STP_PF_KTHREAD | PF_EXITING | PF_STARTING))
      return NULL;
    return current->mm;
  }

  static struct mm_struct *_stp_setup_proc_mm(void)
  {
    mm = current->mm;
    #Return mm as a convenience
    return mm;
  }