All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "acme@kernel.org" <acme@kernel.org>,
	"eranian@google.com" <eranian@google.com>,
	"andi@firstfloor.org" <andi@firstfloor.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH V2 1/6] perf,core: allow invalid context events to be part of sw/hw groups
Date: Thu, 16 Apr 2015 14:53:41 +0000	[thread overview]
Message-ID: <37D7C6CF3E00A74B8858931C1DB2F077017C9293@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <20150415172856.GA5029@twins.programming.kicks-ass.net>



> 
> On Wed, Apr 15, 2015 at 03:56:11AM -0400, Kan Liang wrote:
> > The event count only be read when the event is already sched_in.
> 
> Yeah, so no. This breaks what groups are. Group events _must_ be co-
> scheduled. You cannot guarantee you can schedule events from another
> PMU.

Why? I think it's similar as sw and hw mixed event group.
group_sched_in will co-schedule all events in sibling_list. 
Invalid context events is already added in sibling_list in
perf_install_in_context.
So all group events will be scheduled together. 
event->pmu guarantee proper add is called.
For invalid context events, everything is global. It never fails to schedule.

> 
> Also, I cannot see how this can possibly work, you cannot put these things
> on the same event_context.

Why not? For a sw and hw mixed event group, they use same
hw event_context. 

Actually, the invalid context events don't have any state to switch 
on context switch. They can attach to any event_context.

> 
> Also, how does this work wrt cpumasks, regular events are per cpu, uncore
> events are per node.

Currently, uncore events is only available on the first cpu of the node.
So if it's a hw and uncore mixed group, only cpu 0 do the group.
For other CPUs, there will be only hw event. 
Perf tool will guarantee it. Here are some examples.

[perf]$ sudo perf record -e '{cycles,uncore_imc_0/cas_count_read/}:S'
-C 0-4 -vvv -- sleep 1
------------------------------------------------------------
perf_event_attr:
  size                             112
  { sample_period, sample_freq }   4000
  sample_type                      IP|TID|TIME|READ|ID|CPU|PERIOD
  read_format                      ID|GROUP
  disabled                         1
  mmap                             1
  comm                             1
  freq                             1
  task                             1
  sample_id_all                    1
  exclude_guest                    1
  mmap2                            1
  comm_exec                        1
------------------------------------------------------------
sys_perf_event_open: pid -1  cpu 0  group_fd -1  flags 0x8
sys_perf_event_open: pid -1  cpu 1  group_fd -1  flags 0x8
sys_perf_event_open: pid -1  cpu 2  group_fd -1  flags 0x8
sys_perf_event_open: pid -1  cpu 3  group_fd -1  flags 0x8
sys_perf_event_open: pid -1  cpu 4  group_fd -1  flags 0x8
------------------------------------------------------------
perf_event_attr:
  type                             15
  size                             112
  config                           304
  sample_type                      IP|TID|TIME|READ|ID|CPU|PERIOD
  read_format                      ID|GROUP
  freq                             1
  sample_id_all                    1
  exclude_guest                    1
------------------------------------------------------------
sys_perf_event_open: pid -1  cpu 0  group_fd 3  flags 0x8
mmap size 528384B
perf event ring buffer mmapped per cpu



[perf]$ sudo perf stat -e '{cycles,uncore_imc_0/cas_count_read/}' -C 0-4 
--per-core -- sleep 1

 Performance counter stats for 'CPU(s) 0-4':

S0-C0           1            1367712      cycles                                                        (100.00%)
S0-C0           1               0.17 MiB  uncore_imc_0/cas_count_read/
S0-C1           1             982923      cycles
S0-C1           0      <not counted> MiB  uncore_imc_0/cas_count_read/
S0-C2           1             958585      cycles
S0-C2           0      <not counted> MiB  uncore_imc_0/cas_count_read/
S0-C3           1             978161      cycles
S0-C3           0      <not counted> MiB  uncore_imc_0/cas_count_read/
S0-C4           1             976012      cycles
S0-C4           0      <not counted> MiB  uncore_imc_0/cas_count_read/

       1.001151765 seconds time elapsed


> 
> There is so much broken stuff here without explanation its not funny.
> 
> Please explain how this does not completely wreck everything?

OK. I will refine the description when questions as above are addressed.

Thanks,
Kan

  reply	other threads:[~2015-04-16 14:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-15  7:56 [PATCH V2 1/6] perf,core: allow invalid context events to be part of sw/hw groups Kan Liang
2015-04-15  7:56 ` [PATCH V2 2/6] perf evsel: Set evsel->cpus to the evlist->cpus when not constrained Kan Liang
2015-04-15  7:56 ` [PATCH V2 3/6] perf,tools: get real cpu id for print_aggr Kan Liang
2015-04-15  7:56 ` [PATCH V2 4/6] perf,tools: check and re-organize evsel cpu maps Kan Liang
2015-04-16 16:33   ` Mark Rutland
2015-04-15  7:56 ` [PATCH V2 5/6] perf,tools: open/mmap event uses event's cpu map Kan Liang
2015-04-15  7:56 ` [PATCH V2 6/6] perf/x86/intel/uncore: do not implicitly set uncore event cpu Kan Liang
2015-04-16 16:36   ` Mark Rutland
2015-04-15 16:15 ` [PATCH V2 1/6] perf,core: allow invalid context events to be part of sw/hw groups Peter Zijlstra
2015-04-15 16:21   ` Andi Kleen
2015-04-15 16:55     ` Peter Zijlstra
2015-04-15 17:28 ` Peter Zijlstra
2015-04-16 14:53   ` Liang, Kan [this message]
2015-04-16 16:31 ` Mark Rutland
2015-04-16 16:43   ` Mark Rutland
2015-04-16 17:16   ` Mark Rutland
2015-04-16 21:23   ` Andi Kleen
2015-04-17  9:47     ` Mark Rutland
2015-04-18  0:47       ` Andi Kleen
2015-04-20 10:15         ` Mark Rutland
2015-04-20 16:57           ` Andi Kleen

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=37D7C6CF3E00A74B8858931C1DB2F077017C9293@SHSMSX103.ccr.corp.intel.com \
    --to=kan.liang@intel.com \
    --cc=acme@kernel.org \
    --cc=andi@firstfloor.org \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.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.