[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250813082524.GJ4067720@noisy.programming.kicks-ass.net>
Date: Wed, 13 Aug 2025 10:25:24 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: tglx@...utronix.de, linux-kernel@...r.kernel.org,
torvalds@...uxfoundation.org, mingo@...nel.org, namhyung@...nel.org,
acme@...hat.com, kees@...nel.org
Subject: Re: [PATCH v3 06/15] perf: Move common code into both rb and aux
branches
On Wed, Aug 13, 2025 at 06:55:51AM +0100, Lorenzo Stoakes wrote:
> On Tue, Aug 12, 2025 at 12:39:04PM +0200, Peter Zijlstra wrote:
> > if (cond) {
> > A;
> > } else {
> > B;
> > }
> > C;
> >
> > into
> >
> > if (cond) {
> > A;
> > C;
> > } else {
> > B;
> > C;
> > }
> >
>
> Hm we're doing more than that here though, we're refactoring other stuff at
> the same time.
>
> I guess you're speaking broad strokes here, but maybe worth mentioniing the
> tricksy hobbitses around the rb_has_aux() bit.
Does something like so clarify:
Notably C has a success branch and both A and B have two places for
success. For A (rb case), duplicate the success case because later
patches will result in them no longer being identical. For B (aux
case), share using goto (cleaned up later).
> Anyway LGTM so:
>
> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
>
> > Suggested-by: Thomas Gleixner <tglx@...utronix.de>
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> > ---
> > kernel/events/core.c | 25 +++++++++++++++----------
> > 1 file changed, 15 insertions(+), 10 deletions(-)
> >
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -7043,6 +7043,8 @@ static int perf_mmap(struct file *file,
> > ret = 0;
> > /* We need the rb to map pages. */
> > rb = event->rb;
> > + perf_mmap_account(vma, user_extra, extra);
> > + atomic_inc(&event->mmap_count);
> > goto unlock;
> > }
> >
> > @@ -7083,6 +7085,9 @@ static int perf_mmap(struct file *file,
> > perf_event_init_userpage(event);
> > perf_event_update_userpage(event);
> > ret = 0;
> > +
> > + perf_mmap_account(vma, user_extra, extra);
> > + atomic_inc(&event->mmap_count);
> > } else {
> > /*
> > * AUX area mapping: if rb->aux_nr_pages != 0, it's already
> > @@ -7127,11 +7132,12 @@ static int perf_mmap(struct file *file,
> > if (rb_has_aux(rb)) {
> > atomic_inc(&rb->aux_mmap_count);
> > ret = 0;
> > - goto unlock;
> > + goto aux_success;
> > }
> >
> > if (!perf_mmap_calc_limits(vma, &user_extra, &extra)) {
> > ret = -EPERM;
> > + atomic_dec(&rb->mmap_count);
> > goto unlock;
> > }
> >
> > @@ -7142,20 +7148,19 @@ static int perf_mmap(struct file *file,
> >
> > ret = rb_alloc_aux(rb, event, vma->vm_pgoff, nr_pages,
> > event->attr.aux_watermark, flags);
> > - if (!ret) {
> > - atomic_set(&rb->aux_mmap_count, 1);
> > - rb->aux_mmap_locked = extra;
> > + if (ret) {
>
> You dropped the 'AUX allocation failed' comment here, but honestly I think
> that's fine, it's pretty obvious that's the case given the literal previous
> line is you trying the AUX allocation... :)
Yes that :-)
Powered by blists - more mailing lists