[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160923172615.GU3078@tassilo.jf.intel.com>
Date: Fri, 23 Sep 2016 10:26:15 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
vince@...ter.net, eranian@...gle.com,
Arnaldo Carvalho de Melo <acme@...radead.org>,
tglx@...utronix.de
Subject: Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer
allocation
> Afaict there's no actual need to hide the AUX buffer for this sampling
> stuff; the user knows about all this and can simply mmap() the AUX part.
> The sample could either point to locations in the AUX buffer, or (as I
> think this code does) memcpy bits out.
This would work for perf, but not for the core dump case below.
> Ideally we'd pass the AUX-event into the syscall, that way you avoid all
> the find_aux_event crud. I'm not sure we want to overload the group_fd
> thing more (its already very hard to create counter groups in a cgroup
> for example) ..
>
> Coredump was mentioned somewhere, but I'm not sure I've seen
> code/interfaces for that. How was that envisioned to work?
The idea was to have a rlimit that enables PT running as a ring buffer
in the background. If something crashes the ring buffer is dumped
as part of the core dump, and then gdb can tell you how you crashed.
This extends what gdb already does explicitly today using perf
API calls.
-Andi
Powered by blists - more mailing lists