login
Login
/
Register
Search
Search this site:
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2010
»
November
»
26
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
view
thread
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
[view in full thread]
From: Lin Ming
Subject:
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
Date: Friday, November 26, 2010 - 1:29 am
On Fri, Nov 26, 2010 at 4:18 PM, Stephane Eranian <eranian@google.com> wrote:
quoted text
> On Fri, Nov 26, 2010 at 6:15 AM, Lin Ming <lin@ming.vg> wrote: >> On Tue, Nov 23, 2010 at 6:17 PM, Stephane Eranian <eranian@google.com> wrote: >>> Lin, >>> >>> On Sun, Nov 21, 2010 at 1:01 PM, Lin Ming <ming.m.lin@intel.com> wrote: >>>> +static void uncore_pmu_enable_all(void) >>>> +{ >>>> + u64 ctrl; >>>> + >>>> + /* >>>> + * (0xFULL << 48): 1 of the 4 cores can receive NMI each time >>>> + * but we don't know which core will receive the NMI when overflow happens >>>> + */ >>> >>> That does not sound right. If you set bit 48-51 to 1, then all 4 cores >>> will receive EVERY >>> interrupt, i.e., it's a broadcast. That seems to contradict your >>> comment: 1 of the 4. Unless >>> you meant, they all get the interrupt and one will handle it, the >>> other will find nothing to >>> process. But I don't see the atomic op that would make this true in >>> uncore_handle_irq(). >> >> Stephane, >> >> The interrupt model is strange, it behaves differently when HT on/off. >> >> If HT is off, all 4 cores will receive every interrupt, i.e., it's a broadcast. >> > That's if yo set the mask to 0xf, right?
Right.
quoted text
> > In the perf_event model, given that any one of the 4 cores can be used > to program uncore events, you have no choice but to broadcast to all > 4 cores. Each has to demultiplex and figure out which of its counters > have overflowed.
This is what my upcoming v3 patches doing.
quoted text
> >> If HT is on, only 1 of the 4 cores will receive the interrupt(both >> Threads in that core receive the interrupt), >> and it can't be determined which core will receive the interrupt. >> >> Did you ever observe this? >> > No because I never set more than one bit in the mask. > >> I tried to set the mask 0xff when HT is on, but kernel panics, because >> the reserve bits are set. > > Let me check on this. It would seem to imply that in HT mode, both threads > necessarily receive the interrupts. > > Was that on Nehalem or Westmere?
Nehalem. Thanks, Lin Ming --
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
Messages in current thread:
[RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Lin Ming
, (Sun Nov 21, 5:01 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Andi Kleen
, (Sun Nov 21, 5:46 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Lin Ming
, (Sun Nov 21, 7:04 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Andi Kleen
, (Sun Nov 21, 10:00 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Peter Zijlstra
, (Sun Nov 21, 10:44 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Stephane Eranian
, (Tue Nov 23, 3:00 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Stephane Eranian
, (Tue Nov 23, 3:17 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Lin Ming
, (Tue Nov 23, 6:33 pm)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Lin Ming
, (Wed Nov 24, 2:55 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Lin Ming
, (Wed Nov 24, 5:24 pm)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Peter Zijlstra
, (Wed Nov 24, 11:09 pm)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Lin Ming
, (Wed Nov 24, 11:27 pm)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Stephane Eranian
, (Thu Nov 25, 1:48 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Stephane Eranian
, (Thu Nov 25, 2:10 pm)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Lin Ming
, (Thu Nov 25, 10:15 pm)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Stephane Eranian
, (Fri Nov 26, 1:18 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Lin Ming
, (Fri Nov 26, 1:29 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Stephane Eranian
, (Fri Nov 26, 1:33 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Lin Ming
, (Fri Nov 26, 2:00 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Stephane Eranian
, (Fri Nov 26, 3:06 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Peter Zijlstra
, (Fri Nov 26, 4:24 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Stephane Eranian
, (Fri Nov 26, 4:25 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Peter Zijlstra
, (Fri Nov 26, 4:36 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Stephane Eranian
, (Fri Nov 26, 4:41 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Lin Ming
, (Fri Nov 26, 9:25 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Lin Ming
, (Tue Nov 30, 8:21 pm)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Lin Ming
, (Tue Nov 30, 8:28 pm)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Peter Zijlstra
, (Wed Dec 1, 4:37 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Stephane Eranian
, (Wed Dec 1, 6:04 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Andi Kleen
, (Wed Dec 1, 7:08 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Peter Zijlstra
, (Wed Dec 1, 7:18 am)
Re: [RFC PATCH 2/3 v2] perf: Implement Nehalem uncore pmu
, Lin Ming
, (Wed Dec 1, 10:26 pm)
Navigation
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
Greg KH
Og dreams of kernels
Jens Axboe
[PATCH 31/33] Fusion: sg chaining support
Arnd Bergmann
Re: finding your own dead "CONFIG_" variables
Mark Brown
[PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset
Tony Breeds
[LGUEST] Look in object dir for .config
git
:
Brian Downing
Re: Git in a Nutshell guide
John Benes
Re: master has some toys
Matthias Lederhofer
[PATCH 4/7] introduce GIT_WORK_TREE to specify the work tree
Alexander Sulfrian
[RFC/PATCH] RE: git calls SSH_ASKPASS even if DISPLAY is not set
Junio C Hamano
Re: Rss produced by git is not valid xml?
git-commits-head
:
Linux Kernel Mailing List
iSeries: fix section mismatch in iseries_veth
Linux Kernel Mailing List
ixbge: remove TX lock and redo TX accounting.
Linux Kernel Mailing List
ixgbe: fix several counter register errata
Linux Kernel Mailing List
b43: fix build with CONFIG_SSB_PCIHOST=n
Linux Kernel Mailing List
9p: block-based virtio client
linux-netdev
:
Michael Breuer
Re: [PATCH] af_packet: Don't use skb after dev_queue_xmit()
Michael Breue