public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Chris Friesen" <cfriesen@nortel.com>
To: eranian@gmail.com
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Vince Weaver <vince@deater.net>, Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Eric Dumazet <dada1@cosmosbay.com>,
	Robert Richter <robert.richter@amd.com>,
	Arjan van de Veen <arjan@infradead.org>,
	Peter Anvin <hpa@zytor.com>, Paul Mackerras <paulus@samba.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [patch] Performance Counters for Linux, v3
Date: Mon, 15 Dec 2008 16:32:14 -0600	[thread overview]
Message-ID: <4946DAEE.3050402@nortel.com> (raw)
In-Reply-To: <7c86c4470812150650t3b96d571nba14be2028fa9d0c@mail.gmail.com>

stephane eranian wrote:
> On Fri, Dec 12, 2008 at 8:45 PM, Chris Friesen <cfriesen@nortel.com> wrote:
> 
>>stephane eranian wrote:
>>
>>
>>>What happens in the following test case:
>>>
>>>  - 2-way system (cpu0, cpu1)
>>>
>>>  - on cpu0, two processes P1, P2, each self-monitoring and counting event
>>>E1.
>>>    Event E1 can only be measured on counter C1.
>>>
>>>  - on cpu1, there is a cpu-wide session, monitoring event E1, thus using
>>>C1
>>>
>>>  - the scheduler decides to migrate P1 onto CPU1. You now have a
>>>conflict on C1.
>>>
>>>How is this managed?
>>
>>Prevent the load balancer from moving P1 onto cpu1?
>>
> 
> You don't want to do that.
> 
> There was a reason why the scheduler decided to move the task.
> Now, because of monitoring you would change the behavior of the task
> and scheduler.
> Monitoring should be unintrusive. You want the task/scheduler to
> behave as if no monitoring
> was present otherwise what is it you are actually measuring?

In a scenario where the system physically cannot gather the desired data 
without influencing the behaviour of the program, I see two options:

1) limit the behaviour of the system to ensure that we can gather the 
performance monitoring data as specified

2) limit the performance monitoring to minimize any influence on the 
program, and report the fact that performance monitoring was limited.

You've indicated that you don't want option 1, so I assume that you 
prefer option 2.  In the above scenario, how would _you_ handle it?


Chris


  reply	other threads:[~2008-12-15 22:33 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-11 15:52 [patch] Performance Counters for Linux, v3 Ingo Molnar
2008-12-11 18:02 ` Vince Weaver
2008-12-12  8:25   ` Peter Zijlstra
2008-12-12  8:35     ` stephane eranian
2008-12-12  8:51       ` Peter Zijlstra
2008-12-12  9:00         ` Peter Zijlstra
2008-12-12  9:07           ` Ingo Molnar
2008-12-12  8:59     ` stephane eranian
2008-12-12  9:23       ` Peter Zijlstra
2008-12-12 10:21         ` Robert Richter
2008-12-12 10:59           ` Christoph Hellwig
2008-12-12 11:35             ` Robert Richter
2008-12-12 16:45         ` Chris Friesen
2008-12-12 17:42         ` stephane eranian
2008-12-12 18:01           ` stephane eranian
2008-12-12 19:45             ` Chris Friesen
2008-12-15 14:50               ` stephane eranian
2008-12-15 22:32                 ` Chris Friesen [this message]
2008-12-17  7:45                   ` stephane eranian
2008-12-14 23:13             ` Ingo Molnar
2008-12-15  0:37               ` Paul Mackerras
2008-12-15 12:58                 ` stephane eranian
2008-12-15 14:42                 ` stephane eranian
2008-12-15 20:58               ` stephane eranian
2008-12-15 22:53               ` Paul Mackerras
2008-12-13 11:17           ` Peter Zijlstra
2008-12-13 13:48             ` Henrique de Moraes Holschuh
2008-12-13 17:44             ` stephane eranian
2008-12-14  1:02             ` Paul Mackerras
2008-12-14 22:37               ` Ingo Molnar
2008-12-15  0:50                 ` Paul Mackerras
2008-12-15 13:02                   ` stephane eranian
2008-12-12 17:03     ` Samuel Thibault
2008-12-12 17:11       ` Peter Zijlstra
2008-12-12 18:18     ` Vince Weaver
2008-12-11 18:35 ` Andrew Morton
2008-12-12  6:22   ` Ingo Molnar
2008-12-11 19:11 ` Tony Luck
2008-12-11 19:34   ` Ingo Molnar
2008-12-12  8:29     ` Peter Zijlstra
2008-12-12  8:54       ` Ingo Molnar
2008-12-12 13:42       ` Andi Kleen
2008-12-14 14:51 ` Performance counter API review was " Andi Kleen
2009-02-02 20:03   ` Corey Ashford
2009-02-02 20:33     ` Peter Zijlstra
2009-02-03 16:53       ` Maynard Johnson
2009-02-04  2:18       ` Paul Mackerras
2009-02-04  2:32         ` Nathan Lynch
2009-02-04  8:45         ` Peter Zijlstra
2009-02-04 10:47           ` Paul Mackerras
2009-02-04 10:51             ` Peter Zijlstra
  -- strict thread matches above, loose matches on Subject: below --
2008-12-11 22:05 William Cohen

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=4946DAEE.3050402@nortel.com \
    --to=cfriesen@nortel.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=dada1@cosmosbay.com \
    --cc=davem@davemloft.net \
    --cc=eranian@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=robert.richter@amd.com \
    --cc=tglx@linutronix.de \
    --cc=vince@deater.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox