lkml.org 
[lkml]   [2013]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC] perf: mmap2 not covering VM_CLONE regions
From
On Mon, Sep 30, 2013 at 6:54 PM, Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, Sep 30, 2013 at 06:48:55PM +0200, Stephane Eranian wrote:
> > On Mon, Sep 30, 2013 at 6:15 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > > On Mon, Sep 30, 2013 at 05:44:41PM +0200, Stephane Eranian wrote:
> > >> Hi,
> > >>
> > >> I was alerted by people trying to use the PERF_RECORD_MMAP2
> > >> record to disambiguate virtual address mappings that there is a case
> > >> where the record does not contain enough information.
> > >>
> > >> As you know, the MMAP2 record adds the major, minor, ino number,
> > >> inode generation numbers to a mapping. But it does that only for
> > >> file or pseudo -file backed mappings. That covers file mmaps and also
> > >> SYSV shared memory segments.
> > >>
> > >> However there is a another kind of situation that arises in some
> > >> multi-process benchmarks where a region of memory is cloned
> > >> using VM_CLONE. As such, the virtual addresses match between
> > >> the processes but the major, minor, inode, inode generation fields
> > >> are all zeroes because there is no inode associated with the mapping.
> > >> Yet, it is important for the tool to know the mappings between the
> > >> processes are pointing to the same physical data.
> > >>
> > >> We need to cover this case and I am seeking for advice on how to
> > >> best address this need given that we discarded using the plain physical
> > >> address for disambiguation.
> > >
> > > Urgh.. who in his bloody mind is playing VM_CLNOE games that is not
> > > pthread_creatE() ?
> >
> > Some matrix multiply benchmark, I guess.
>
> So the problem is that we don't have a user visible address space
> identifier; with CLONE_THREAD we have the thread group id that acts
> like this. But for bare CLONE_VM usage there's nothing afaik.


From the tool's perspective, the MMAP2 record must contain enough information
to identify that the mapping points to the same physical pages in that
particular
case (multi-process + VM_CLONE). As we have it now all inode-related fields
are zero which is useless (indicates: no info). In other words, we need to make
up some unique number and stash it in the maj.min,ino triplet somehow.


\
 
 \ /
  Last update: 2013-10-01 13:41    [W:0.112 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site