[lkml]   [2020]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 02/26] perf: Introduce mmap3 version of mmap event
On 15/09/20 1:00 am, Arnaldo Carvalho de Melo wrote:
> Em Mon, Sep 14, 2020 at 09:39:07PM +0200, Jiri Olsa escreveu:
>> On Mon, Sep 14, 2020 at 12:28:41PM -0300, Arnaldo Carvalho de Melo wrote:
>>> Em Mon, Sep 14, 2020 at 02:38:27PM +0900, Namhyung Kim escreveu:
>>>> On Mon, Sep 14, 2020 at 6:03 AM Jiri Olsa <> wrote:
>>>>> Add new version of mmap event. The MMAP3 record is an
>>>>> augmented version of MMAP2, it adds build id value to
>>>>> identify the exact binary object behind memory map:
>>>>> struct {
>>>>> struct perf_event_header header;
>>>>> u32 pid, tid;
>>>>> u64 addr;
>>>>> u64 len;
>>>>> u64 pgoff;
>>>>> u32 maj;
>>>>> u32 min;
>>>>> u64 ino;
>>>>> u64 ino_generation;
>>>>> u32 prot, flags;
>>>>> u32 reserved;
>>> What for this reserved? its all nicely aligned already, u64 followed by
>>> two u32 (prot, flags).
>>>>> u8 buildid[20];
>>>> Do we need maj, min, ino, ino_generation for mmap3 event?
>>>> I think they are to compare binaries, then we can do it with
>>>> build-id (and I think it'd be better)..
>>> Humm, I thought MMAP2 would be a superset of MMAP and MMAP3 would be a
>>> superset of MMAP2.
>>> If we want to ditch useless stuff, then trow away pid, tid too, as we
>>> can select those via sample_type.
>>> Having said that, at this point I don't even know if adding new
>>> PERF_RECORD_ that are an update for a preexisting one is the right way
>>> to proceed.
>>> Perhaps we should attach a BPF program to point where a mmap/munmap is
>>> being done (perf_event_mmap()) and allow userspace to ask for whatever
>>> it wants? With a kprobes there right now we can implement this MMAP3
>>> easily, no?
>> hmm, I'm always woried about solutions based on kprobes,
>> because once the function is moved/removed you're screwed
>> and need to keep up with function name changes and be
>> backward compatible..
> Well, I'm not advocating to have it as kprobes permanently, but we can
> implement it now using a kprobes, i.e. systems wouldn't have to have its
> kernel updated to have this feature, but once then need, for some other
> reason, to have their kernel upgraded, then perf would notice that there
> is a tracepoint for that and would happily use it.
> So we would be able to use that tracepoint with things like ftrace,
> bpftrace, everything that knows about tracepoints, and perf would get
> build-ids and whatever else is needed to have a mmap record, in the
> future we could even ask for some more (or less) according to the what
> is needed for some new feature.
> I.e. the point wasn't about kprobes was about using BPF to state what
> we want to collect when a mmap is being put in place.

Isn't the problem with krpobes / tracepoints etc that non-privileged users
can't use them.

 \ /
  Last update: 2020-09-15 07:41    [W:0.119 / U:16.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site