Peter Zijlstra writes:
> On Fri, Aug 09, 2019 at 03:32:39PM +0300, Alexander Shishkin wrote:
>> The other problem is sampling SW events, that would require a ctx->lock
>> to prevent racing with event_function_call()s from other cpus, resulting
>> in somewhat cringy "if (!in_nmi()) raw_spin_lock(.
On Fri, Aug 09, 2019 at 03:32:39PM +0300, Alexander Shishkin wrote:
> The other problem is sampling SW events, that would require a ctx->lock
> to prevent racing with event_function_call()s from other cpus, resulting
> in somewhat cringy "if (!in_nmi()) raw_spin_lock(...)", but I don't have
> bette
Alexander Shishkin writes:
> Peter Zijlstra writes:
>
>> On Tue, Jun 19, 2018 at 01:47:25PM +0300, Alexander Shishkin wrote:
>>> Right, the SW stuff may then race with event_function_call() stuff. Hmm.
>>> For the HW stuff, I'm hoping that some kind of a sleight of hand may
>>> suffice. Let me t
Peter Zijlstra writes:
> On Tue, Jun 19, 2018 at 01:47:25PM +0300, Alexander Shishkin wrote:
>> Right, the SW stuff may then race with event_function_call() stuff. Hmm.
>> For the HW stuff, I'm hoping that some kind of a sleight of hand may
>> suffice. Let me think some more.
>
> I currently don'
Peter Zijlstra writes:
> On Tue, Jun 19, 2018 at 01:47:25PM +0300, Alexander Shishkin wrote:
>> On Thu, Jun 14, 2018 at 10:20:22PM +0200, Peter Zijlstra wrote:
>
>> > More yuck...
>> >
>> > You rreally should not be calling these pmu::methods, they're meant to
>> > be used from _interrupt_ not N
On Tue, Jun 19, 2018 at 01:47:25PM +0300, Alexander Shishkin wrote:
> On Thu, Jun 14, 2018 at 10:20:22PM +0200, Peter Zijlstra wrote:
> > More yuck...
> >
> > You rreally should not be calling these pmu::methods, they're meant to
> > be used from _interrupt_ not NMI context. Using them like this
On Thu, Jun 14, 2018 at 09:47:20PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 12, 2018 at 10:51:15AM +0300, Alexander Shishkin wrote:
> > @@ -6112,6 +6219,32 @@ void perf_prepare_sample(struct perf_event_header
> > *header,
> >
> > if (sample_type & PERF_SAMPLE_PHYS_ADDR)
> > dat
On Thu, Jun 14, 2018 at 09:39:17PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 14, 2018 at 09:25:13PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 12, 2018 at 10:51:15AM +0300, Alexander Shishkin wrote:
> > > @@ -882,6 +890,7 @@ struct perf_sample_data {
> > >*/
> > > u64
On Thu, Jun 14, 2018 at 10:20:22PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 12, 2018 at 10:51:15AM +0300, Alexander Shishkin wrote:
> > +static unsigned long perf_aux_sample_size(struct perf_event *event,
> > + struct perf_sample_data *data,
> > +
On Tue, Jun 12, 2018 at 10:51:15AM +0300, Alexander Shishkin wrote:
> +static unsigned long perf_aux_sample_size(struct perf_event *event,
> + struct perf_sample_data *data,
> + size_t size)
> +{
> + struct perf_event *
On Tue, Jun 12, 2018 at 10:51:15AM +0300, Alexander Shishkin wrote:
> + ret = rb_output_aux(rb, data->aux.from, data->aux.to,
> + (aux_copyfn)perf_output_copy, handle);
If you look closely, you'll find that perf_output_copy() as 'unsigned
int' return type and your aux_c
On Tue, Jun 12, 2018 at 10:51:15AM +0300, Alexander Shishkin wrote:
> @@ -6112,6 +6219,32 @@ void perf_prepare_sample(struct perf_event_header
> *header,
>
> if (sample_type & PERF_SAMPLE_PHYS_ADDR)
> data->phys_addr = perf_virt_to_phys(data->addr);
> +
> + if (sample_typ
On Thu, Jun 14, 2018 at 09:25:13PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 12, 2018 at 10:51:15AM +0300, Alexander Shishkin wrote:
> > @@ -882,6 +890,7 @@ struct perf_sample_data {
> > */
> > u64 addr;
> > struct perf_raw_record *raw;
> > + str
On Tue, Jun 12, 2018 at 10:51:15AM +0300, Alexander Shishkin wrote:
> @@ -416,6 +418,7 @@ struct perf_event_attr {
> __u32 aux_watermark;
> __u16 sample_max_stack;
> __u16 __reserved_2; /* align to __u64 */
> + __u64 aux_sample_size;
> };
Do we really need a __u64
On Tue, Jun 12, 2018 at 10:51:15AM +0300, Alexander Shishkin wrote:
> @@ -882,6 +890,7 @@ struct perf_sample_data {
>*/
> u64 addr;
> struct perf_raw_record *raw;
> + struct perf_aux_record aux;
> struct perf_branch_stack
AUX data can be used to annotate perf events such as performance counters
or tracepoints/breakpoints by including it in sample records when
PERF_SAMPLE_AUX flag is set. Such samples would be instrumental in debugging
and profiling by providing, for example, a history of instruction flow
leading up
16 matches
Mail list logo
