All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Song Liu <songliubraving@fb.com>
Cc: open list <linux-kernel@vger.kernel.org>,
	Kernel Team <Kernel-team@fb.com>,
	"acme@kernel.org" <acme@kernel.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Alexey Budankov <alexey.budankov@linux.intel.com>,
	Namhyung Kim <namhyung@kernel.org>, Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH v6] perf: Sharing PMU counters across compatible events
Date: Wed, 6 Nov 2019 21:44:19 +0100	[thread overview]
Message-ID: <20191106204419.GI3079@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <168F3761-98CF-4E91-B911-ECB9FCD68F0C@fb.com>

On Wed, Nov 06, 2019 at 05:40:29PM +0000, Song Liu wrote:
> > On Nov 6, 2019, at 1:14 AM, Peter Zijlstra <peterz@infradead.org> wrote:

> >> OTOH, non-cgroup event could also be inactive. For example, when we have 
> >> to rotate events, we may schedule slave before master. 
> > 
> > Right, although I suppose in that case you can do what you did in your
> > patch here. If someone did IOC_DISABLE on the master, we'd have to
> > re-elect a master -- obviously (and IOC_ENABLE).
> 
> Re-elect master on IOC_DISABLE is good. But we still need work for ctx
> rotation. Otherwise, we need keep the master on at all time. 

I meant to says that for the rotation case we can do as you did here, if
we do add() on a slave, add the master if it wasn't add()'ed yet.

> >> And if the master is in an event group, it will be more complicated...
> > 
> > Hurmph, do you actually have that use-case? And yes, this one is tricky.
> > 
> > Would it be sufficient if we disallow group events to be master (but
> > allow them to be slaves) ?
> 
> Maybe we can solve this with an extra "first_active" pointer in perf_event.
> first_active points to the first event that being added by event_pmu_add(). 
> Then we need something like:
> 
> event_pmu_add(event)
> {
> 	if (event->dup_master->first_active) {
> 		/* sync with first_active */
> 	} else {
> 		/* this event will be the first_active */
> 		event->dup_master->first_active = event;
> 		pmu->add(event);
> 	}
> }

I'm confused on what exactly you're trying to solve with the
first_active thing. The problem with the group event as master is that
you then _must_ schedule the whole group, which is obviously difficult.

> >> If we do GFP_ATOMIC in perf_event_alloc(), maybe with an extra option, we
> >> don't need the tmp_master hack. So we only allocate master when we will 
> >> use it. 
> > 
> > You can't, that's broken on -RT. ctx->lock is a raw_spinlock_t and
> > allocator locks are spinlock_t.
> 
> How about we add another step in __perf_install_in_context(), like
> 
> __perf_install_in_context()
> {
> 	bool alloc_master;
> 
> 	perf_ctx_lock();
> 	alloc_master = find_new_sharing(event, ctx);
> 	perf_ctx_unlock();
> 	
> 	if (alloc_master)
> 		event->dup_master = perf_event_alloc();
> 	/* existing logic of __perf_install_in_context() */
> 
> }
> 
> In this way, we only allocate the master event when necessary, and it
> is outside of the locks. 

It's still broken on -RT, because __perf_install_in_context() is in
hardirq context (IPI) and the allocator locks are spinlock_t.


  reply	other threads:[~2019-11-06 20:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-19  5:23 [PATCH v6] perf: Sharing PMU counters across compatible events Song Liu
2019-09-30  5:36 ` Song Liu
2019-10-31 12:43 ` Peter Zijlstra
2019-10-31 16:29   ` Song Liu
2019-11-05 17:11     ` Song Liu
2019-11-05 20:16       ` Peter Zijlstra
2019-11-05 23:06         ` Song Liu
2019-11-06  9:14           ` Peter Zijlstra
2019-11-06 17:40             ` Song Liu
2019-11-06 20:44               ` Peter Zijlstra [this message]
2019-11-06 22:23                 ` Song Liu
2019-11-05 23:51 ` Song Liu
2019-11-06  8:56   ` Peter Zijlstra

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=20191106204419.GI3079@worktop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=Kernel-team@fb.com \
    --cc=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=alexey.budankov@linux.intel.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namhyung@kernel.org \
    --cc=songliubraving@fb.com \
    --cc=tj@kernel.org \
    /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.