All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maynard Johnson <maynardj@us.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>,
	Andi Kleen <andi@firstfloor.org>,
	Paul Mackerras <paulus@samba.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Stephane Eranian <eranian@googlemail.com>,
	Eric Dumazet <dada1@cosmosbay.com>,
	Robert Richter <robert.richter@amd.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Peter Anvin <hpa@zytor.com>,
	"David S. Miller" <davem@davemloft.net>,
	perfctr-devel@lists.sourceforge.net
Subject: Re: [patch] Performance Counters for Linux, v4
Date: Fri, 16 Jan 2009 16:14:29 -0600	[thread overview]
Message-ID: <497106C5.60703@us.ibm.com> (raw)
In-Reply-To: <4970CB6F.9000301@linux.vnet.ibm.com>

Corey Ashford wrote:
> Andi Kleen wrote:
>> Paul Mackerras <paulus@samba.org> writes:
>>> The perf counter subsystem will, in Ingo's design, naturally try to
>>> schedule as many counters and groups on as it can.  Given a list of
>>> counters/groups, it could start with the first and keep on trying to
>>> add counters or groups while it can, essentially trying all possible
>>> combinations until it either fills up all the hardware counters or
>>> exhausts the possible combinations.  If it moves all the
>>> counters/groups that do fit on up to the head of the list, and then
>>> rotates them to the back of the list when the timeslice expires, that
>>> would probably be OK.  In fact the computation about what set of
>>> counters/groups to put on should be done when adding/removing a
>>> counter/group and when the timeslice expires, rather than at context
>>> switch time.  (I'm talking about the list of part-time counters/groups
>>> here, of course.)
>> One issue is that PMU counts can cover more than one CPU. One example
>> for this are the Uncore events on Nehalem (which cover a whole socket)
>> or when you are in AnyThreads monitoring mode (then you get events
>> from both SMT siblings in a core)
>>
>> With that you would need to examine other CPU's state at context switch
>> time. Probably not a good idea for scalability.
>>
>> -Andi
>>
> 
> Over time, it seems clear that we will see multi-core processor designs 
> with increasingly large uncore/nest facilities, so this could become 
> more and more of an issue.
Ingo, I'll add my voice to the chorus here.  To reiterate the point, some PMUs count events that are external to the processor cores, and these events cannot be attributed to any one particular CPU -- and certainly not to a particular pid.  The current interface has a restriction that the user cannot pass -1 for both pid and cpu.  But it seems to me that's exactly what would be needed for such off-core events.  Can this feature fit in with the current interface or is some sort of extension needed?

Thanks.
-Maynard
> 
> - Corey
> 
> Corey Ashford
> Software Engineer
> IBM Linux Technology Center, Linux Toolchain
> Beaverton, OR
> 503-578-3507
> cjashfor@us.ibm.com
> 


  reply	other threads:[~2009-01-16 22:14 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-14 21:28 [patch] Performance Counters for Linux, v4 Ingo Molnar
2008-12-15 11:59 ` Paul Mackerras
2008-12-15 12:11 ` Paul Mackerras
2008-12-16 14:22   ` Peter Zijlstra
2008-12-16 23:06     ` Paul Mackerras
2008-12-16 23:51       ` Ingo Molnar
2008-12-17  1:55       ` Andi Kleen
2009-01-16 18:01         ` Corey Ashford
2009-01-16 22:14           ` Maynard Johnson [this message]
2009-01-16 23:11             ` Ingo Molnar
2009-01-17  1:26           ` Paul Mackerras
2009-01-17  9:53             ` Andi Kleen
2008-12-17  2:23       ` [Perfctr-devel] " Dan Terpstra
2008-12-17  7:34       ` stephane eranian
2008-12-15 17:44 ` Vince Weaver
2008-12-15 21:07   ` Vince Weaver
2008-12-15 22:13     ` Paul Mackerras
2008-12-15 21:42   ` Paul Mackerras
2008-12-15 22:03     ` stephane eranian
2008-12-16 14:42     ` Peter Zijlstra
2008-12-16 16:55       ` Vince Weaver
2008-12-16 21:52         ` Paul Mackerras
2008-12-16 12:22 ` Pavel Machek
2008-12-16 12:50   ` Ingo Molnar
2008-12-16 12:57     ` Pavel Machek
2008-12-16 13:03       ` Ingo Molnar
2008-12-16 13:13         ` Arjan van de Ven
2008-12-16 20:04           ` Pavel Machek
2008-12-16 14:45 ` Peter Zijlstra
2008-12-16 15:46 ` [Perfctr-devel] " Martin Cracauer
2008-12-16 17:38 ` Vince Weaver
2008-12-16 19:47   ` Corey Ashford
2008-12-16 20:55     ` Vince Weaver
2008-12-16 19:56 ` [Perfctr-devel] " William Cohen
2008-12-17  1:51   ` Andi Kleen
2008-12-17  1:56     ` Samuel Thibault
     [not found]       ` <d484eb1f0812162357n7a851f2fncc0abaae9bd293a4@mail.gmail.com>
2008-12-17  9:18         ` Andi Kleen
     [not found]           ` <d484eb1f0812170611s597e014cl5fb98d6dd81afd49@mail.gmail.com>
2008-12-17 15:06             ` Andi Kleen
2008-12-17 16:00 ` William Cohen
2008-12-17 20:53   ` Corey Ashford

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=497106C5.60703@us.ibm.com \
    --to=maynardj@us.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=arjan@infradead.org \
    --cc=cjashfor@linux.vnet.ibm.com \
    --cc=dada1@cosmosbay.com \
    --cc=davem@davemloft.net \
    --cc=eranian@googlemail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=perfctr-devel@lists.sourceforge.net \
    --cc=robert.richter@amd.com \
    --cc=tglx@linutronix.de \
    /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.