merged.

When sending these sort of changes, we should always have a

commit <hash> upstream

In the commit messages themselves. That way I can easily check
which versions have the change already, and know that it is a
cherry-pick.

Bruce

In message: [linux-yocto][v5.10/standard/base][PATCH 1/2] perf: Cap allocation 
order at aux_watermark
on 13/07/2021 He Zhe wrote:

> From: Alexander Shishkin <[email protected]>
> 
> Currently, we start allocating AUX pages half the size of the total
> requested AUX buffer size, ignoring the attr.aux_watermark setting. This,
> in turn, makes intel_pt driver disregard the watermark also, as it uses
> page order for its SG (ToPA) configuration.
> 
> Now, this can be fixed in the intel_pt PMU driver, but seeing as it's the
> only one currently making use of high order allocations, there is no
> reason not to fix the allocator instead. This way, any other driver
> wishing to add this support would not have to worry about this.
> 
> Signed-off-by: Alexander Shishkin <[email protected]>
> Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
> Link: 
> https://lkml.kernel.org/r/[email protected]
> 
> perf, pt: Improve data loss
> https://lore.kernel.org/lkml/[email protected]/
> Signed-off-by: He Zhe <[email protected]>
> ---
>  kernel/events/ring_buffer.c | 34 ++++++++++++++++++----------------
>  1 file changed, 18 insertions(+), 16 deletions(-)
> 
> diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
> index ef91ae75ca56..dd49506f7bd8 100644
> --- a/kernel/events/ring_buffer.c
> +++ b/kernel/events/ring_buffer.c
> @@ -674,21 +674,26 @@ int rb_alloc_aux(struct perf_buffer *rb, struct 
> perf_event *event,
>       if (!has_aux(event))
>               return -EOPNOTSUPP;
>  
> -     /*
> -      * We need to start with the max_order that fits in nr_pages,
> -      * not the other way around, hence ilog2() and not get_order.
> -      */
> -     max_order = ilog2(nr_pages);
> -
> -     /*
> -      * PMU requests more than one contiguous chunks of memory
> -      * for SW double buffering
> -      */
>       if (!overwrite) {
> -             if (!max_order)
> -                     return -EINVAL;
> +             /*
> +              * Watermark defaults to half the buffer, and so does the
> +              * max_order, to aid PMU drivers in double buffering.
> +              */
> +             if (!watermark)
> +                     watermark = nr_pages << (PAGE_SHIFT - 1);
>  
> -             max_order--;
> +             /*
> +              * Use aux_watermark as the basis for chunking to
> +              * help PMU drivers honor the watermark.
> +              */
> +             max_order = get_order(watermark);
> +     } else {
> +             /*
> +              * We need to start with the max_order that fits in nr_pages,
> +              * not the other way around, hence ilog2() and not get_order.
> +              */
> +             max_order = ilog2(nr_pages);
> +             watermark = 0;
>       }
>  
>       rb->aux_pages = kcalloc_node(nr_pages, sizeof(void *), GFP_KERNEL,
> @@ -743,9 +748,6 @@ int rb_alloc_aux(struct perf_buffer *rb, struct 
> perf_event *event,
>       rb->aux_overwrite = overwrite;
>       rb->aux_watermark = watermark;
>  
> -     if (!rb->aux_watermark && !rb->aux_overwrite)
> -             rb->aux_watermark = nr_pages << (PAGE_SHIFT - 1);
> -
>  out:
>       if (!ret)
>               rb->aux_pgoff = pgoff;
> -- 
> 2.29.2
> 

In message: [linux-yocto][v5.10/standard/base][PATCH 2/2] perf intel-pt: Use 
aux_watermark
on 13/07/2021 He Zhe wrote:

> From: Alexander Shishkin <[email protected]>
> 
> Turns out, the default setting of attr.aux_watermark to half of the total
> buffer size is not very useful, especially with smaller buffers. The
> problem is that, after half of the buffer is filled up, the kernel updates
> ->aux_head and sets up the next "transaction", while observing that
> ->aux_tail is still zero (as userspace haven't had the chance to update
> it), meaning that the trace will have to stop at the end of this second
> "transaction". This means, for example, that the second PERF_RECORD_AUX in
> every trace comes with TRUNCATED flag set.
> 
> Setting attr.aux_watermark to quarter of the buffer gives enough space for
> the ->aux_tail update to be observed and prevents the data loss.
> 
> The obligatory before/after showcase:
> 
> > # perf_before record -e intel_pt//u -m,8 uname
> > Linux
> > [ perf record: Woken up 6 times to write data ]
> > Warning:
> > AUX data lost 4 times out of 10!
> >
> > [ perf record: Captured and wrote 0.099 MB perf.data ]
> > # perf record -e intel_pt//u -m,8 uname
> > Linux
> > [ perf record: Woken up 4 times to write data ]
> > [ perf record: Captured and wrote 0.039 MB perf.data ]
> 
> The effect is still visible with large workloads and large buffers,
> although less pronounced.
> 
> Signed-off-by: Alexander Shishkin <[email protected]>
> Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
> Link: 
> https://lkml.kernel.org/r/[email protected]
> 
> perf, pt: Improve data loss
> https://lore.kernel.org/lkml/[email protected]/
> Signed-off-by: He Zhe <[email protected]>
> ---
>  tools/perf/arch/x86/util/intel-pt.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tools/perf/arch/x86/util/intel-pt.c 
> b/tools/perf/arch/x86/util/intel-pt.c
> index 082e5f2a415a..3c6745e28f57 100644
> --- a/tools/perf/arch/x86/util/intel-pt.c
> +++ b/tools/perf/arch/x86/util/intel-pt.c
> @@ -776,6 +776,12 @@ static int intel_pt_recording_options(struct 
> auxtrace_record *itr,
>               }
>       }
>  
> +     if (!opts->auxtrace_snapshot_mode && !opts->auxtrace_sample_mode) {
> +             u32 aux_watermark = opts->auxtrace_mmap_pages * page_size / 4;
> +
> +             intel_pt_evsel->core.attr.aux_watermark = aux_watermark;
> +     }
> +
>       intel_pt_parse_terms(intel_pt_pmu->name, &intel_pt_pmu->format,
>                            "tsc", &tsc_bit);
>  
> -- 
> 2.29.2
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10126): 
https://lists.yoctoproject.org/g/linux-yocto/message/10126
Mute This Topic: https://lists.yoctoproject.org/mt/84209750/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to