All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Namhyung Kim <namhyung@kernel.org>,
	linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [RFC] Sharing PMU counters across compatible events
Date: Wed, 13 Dec 2017 11:18:07 +0100	[thread overview]
Message-ID: <20171213101807.GA2883@krava> (raw)
In-Reply-To: <20171211153449.GJ2421075@devbig577.frc2.facebook.com>

On Mon, Dec 11, 2017 at 07:34:49AM -0800, Tejun Heo wrote:
> Hello, Jiri.
> 
> On Wed, Dec 06, 2017 at 12:42:04PM +0100, Jiri Olsa wrote:
> > I see this rather on the hw level, since it concerns HW counters
> > 
> > I think we could detect same (alias) events at the time counters
> > are added/removed on/from the cpu and share their HW part like
> > counter idx, regs and such (struct hw_perf_event_cpu in my changes)
> > 
> > this way it'd be completely transparent for generic code
> 
> I don't quite follow why doing this in arch code is better than
> generic.  Doing this in arch means we'd need to do the same thing
> multiple times for different archs.  Why is that better?

so I can see this to be useful for HW conters only, because
of limited number of regs

as for the higher level on which this could be implemented I
see some pitfals with event rotations as Peter mentioned and
task/cpu contexts scheduling.. while the hw-level implementation
seems pretty straight forward

I'll test the code and let's see ;-)

jirka

  reply	other threads:[~2017-12-13 10:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-01 14:19 [RFC] Sharing PMU counters across compatible events Tejun Heo
2017-12-06 11:42 ` Jiri Olsa
2017-12-11 15:34   ` Tejun Heo
2017-12-13 10:18     ` Jiri Olsa [this message]
2017-12-13 16:15       ` Tejun Heo
2017-12-06 12:35 ` Peter Zijlstra
2017-12-11 15:47   ` Tejun Heo
2017-12-12 22:37     ` Peter Zijlstra
2017-12-13 16:18       ` Tejun Heo

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=20171213101807.GA2883@krava \
    --to=jolsa@redhat.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --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.