lkml.org 
[lkml]   [2013]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] perf: mmap2 not covering VM_CLONE regions

* Stephane Eranian <eranian@google.com> wrote:

> > Instead of a full revert we could just turn off the ABI portion
> > minimally and not recognize it for now. Assuming a more complete
> > solution is in the works for v3.13.
>
> That's a possibility. They are also pieces in the perf tool itself. We
> could certainly make the attr->mmap2 bit disappear.
>
> I think it boils down to how can we uniquely identify virtual mapping to
> the same physical data either via shmat(), files, VM_CLONE. We had all
> covered but the last case with the ino approach. We don't have a
> solution for VM_CLONE yet.

PeterZ didn't like exposing the physical RAM address, right?

Peter: could we expose the page frame number instead? (Maybe mix it with a
random seed through the hash-mixer and expose that.) User-space will thus
be able to discover whether two pages are shared or not, but not extract
other information.

The global MM ID thing looked rather ugly as well.

That way we could drop the inode info as well? That feels a bit hacky too.

Thanks,

Ingo


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