All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lin Ming <ming.m.lin@intel.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Ingo Molnar <mingo@elte.hu>,
	Stephane Eranian <eranian@google.com>,
	Andi Kleen <andi@firstfloor.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Arjan van de Ven <arjan@infradead.org>
Subject: [RFC PATCH 0/3 v2] perf: Add Intel Nehalem uncore pmu support
Date: Sun, 21 Nov 2010 19:59:26 +0800	[thread overview]
Message-ID: <1290340766.2245.121.camel@localhost> (raw)

Hi, all

Sorry for the late update, I was fixing some uncore NMI problem(see
below).
This v2 does not fully work yet, but it addresses most comments of v1.

FYI, below links are the entry for v1.
[DRAFT PATCH 0/3] perf: Add Intel Nehalem uncore pmu support
http://marc.info/?l=linux-kernel&m=128868293025309&w=2
http://marc.info/?l=linux-kernel&m=128868293025298&w=2
http://marc.info/?l=linux-kernel&m=128868296425366&w=2
http://marc.info/?l=linux-kernel&m=128868298125380&w=2

Applied on top of current tip/master(59c5300).

The main change is the uncore NMI handling code.
In the v1, I thought all the 4 cores will receive NMI when any uncore
counter overflows. So each core only handled the counters enabled by
itself in v1.
But actually only 1 of the 4 cores receives NMI each time, and we can't
determine which core receives it. So the NMI handler(running on 1 of the
4 cores) should handle all counters enabled by all 4 cores.

Changelogs of v2:

- modify the NMI handling code to handle all counters enabled by all 4
cores.

- allocate uncore_events[] table dynamically using kmalloc_node() to
avoid unnecessary remote memory accesses. (Stephane Eranian)

- add support for the fixed uncore counter. (Stephane Eranian)

- Handling of exclude_* bits. Uncore PMU measures at all privilege level
all the time. So it doesn't make sense to specify any exclude bits.
(Stephane Eranian)

- let uncore code be more self contained, that is, not include it in
arch/x86/kernel/cpu/perf_event.c (Peter Zijlstra)

- uncore pmu interrupt have its own NMI_DIE notifier entry. (Peter
Zijlstra)

Known bugs:

- When hyper thread is enabled, both HTs will receive the NMI. In this
case, the overflow status bits are not acked correctly.

TODO:

- per-task uncore event should not be allowed. Peter suggested simply
set pmu::task_ctx_nr = perf_invalid_context.

- This whole implementation is per-node, it should be converted to
per-socket. Andi Kleen has commented that using numa_node_id() implies
this implementation can't be used when NUMA is turned off. Better use
the package id.

- add support for uncore address/opcode match thing

As usual, any comment is very appreciated.

Lin Ming 


                 reply	other threads:[~2010-11-21 11:59 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1290340766.2245.121.camel@localhost \
    --to=ming.m.lin@intel.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=andi@firstfloor.org \
    --cc=arjan@infradead.org \
    --cc=eranian@google.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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.