All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Stephane Eranian <eranian@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	mingo@elte.hu, Arnaldo Carvalho de Melo <acme@redhat.com>,
	Jiri Olsa <jolsa@redhat.com>, "Liang, Kan" <kan.liang@intel.com>,
	Song Liu <songliubraving@fb.com>, Ian Rogers <irogers@google.com>
Subject: Re: [PATCH] perf/core: fix multiplexing event scheduling issue
Date: Wed, 23 Oct 2019 11:37:57 +0200	[thread overview]
Message-ID: <20191023093757.GR1817@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CABPqkBRgBegcdNHtXUqkdfJUASjuUYnSkh_cNeqfoO4wF7tnFQ@mail.gmail.com>

On Wed, Oct 23, 2019 at 12:06:43AM -0700, Stephane Eranian wrote:
> On Mon, Oct 21, 2019 at 3:06 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > On Thu, Oct 17, 2019 at 05:27:46PM -0700, Stephane Eranian wrote:

> > > +      * others removed. There is a way to get removed and not be disabled first.
> > > +      */
> > > +     if (ctx->rotate_necessary && ctx->nr_events) {
> > > +             int type = get_event_type(event);
> > > +             /*
> > > +              * In case we removed a pinned event, then we need to
> > > +              * resched for both pinned and flexible events. The
> > > +              * opposite is not true. A pinned event can never be
> > > +              * inactive due to multiplexing.
> > > +              */
> > > +             if (type & EVENT_PINNED)
> > > +                     type |= EVENT_FLEXIBLE;
> > > +             ctx_resched(cpuctx, cpuctx->task_ctx, type);
> > > +     }
> >
> > What you're relying on is that ->rotate_necessary implies ->is_active
> > and there's pending events. And if we tighten ->rotate_necessary you can
> > remove the && ->nr_events.
> >
> Imagine I have 6 events and 4 counters and I do delete them all before
> the timer expires.  Then, I can be in a situation where
> rotate_necessary is still true and yet have no more events in the
> context. That is because only ctx_sched_out() clears rotate_necessary,
> IIRC. So that is why there is the && nr_events. Now, calling
> ctx_resched() with no events wouldn't probably cause any harm, just
> wasted work.

> So if by tightening, I am guessing you mean clearing rotate_necessary
> earlier. But that would be tricky because the only reliable way of
> clearing it is when you know you are about the reschedule everything.
> Removing an event by itself may not be enough to eliminate
> multiplexing.

I think you're over-thinking things. The thing you test 'ctx->nr_events'
has a clear place where it drops to 0.

If we add

	ctx->nr_events--;
+	if (!ctx->nr_events && ctx->rotate_necessary)
+		ctx->rotate_necessary = 0;

to list_del_event(), we can get rid of that.

Further, since we set it on reschedule, I propose you change the above
like:

	if (ctx->rotate_necessary) {
		int type = get_event_type(event);
		/*
		 * comment..
		 */
		if (type & EVENT_PINNED)
			type |= EVENT_FLEXIBLE;
+		/*
+		 * Will be reset by ctx_resched()'s flexible_sched_in().
+		 */
+		ctx->rotate_necessary = 0;
		ctx_resched(cpuctx, cpuctx->task_ctx, type);
	}

Then rotate_necessary will be tight.

  reply	other threads:[~2019-10-23  9:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-18  0:27 [PATCH] perf/core: fix multiplexing event scheduling issue Stephane Eranian
2019-10-18  6:13 ` Song Liu
2019-10-18  6:19   ` Stephane Eranian
2019-10-18  6:55     ` Song Liu
2019-10-21 10:05 ` Peter Zijlstra
2019-10-23  7:06   ` Stephane Eranian
2019-10-23  9:37     ` Peter Zijlstra [this message]
2019-10-23 15:29       ` Peter Zijlstra
2019-10-21 10:20 ` Peter Zijlstra
2019-10-23  7:30   ` Stephane Eranian
2019-10-23 11:02     ` Peter Zijlstra
2019-10-23 17:44       ` Stephane Eranian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191023093757.GR1817@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@redhat.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@redhat.com \
    --cc=kan.liang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=songliubraving@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.