linux-kernel - Re: [patch] Performance Counters for Linux, v3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 15 Dec 2008 16:32:14 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	eranian@...il.com
CC:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Vince Weaver <vince@...ter.net>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Eric Dumazet <dada1@...mosbay.com>,
	Robert Richter <robert.richter@....com>,
	Arjan van de Veen <arjan@...radead.org>,
	Peter Anvin <hpa@...or.com>, Paul Mackerras <paulus@...ba.org>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [patch] Performance Counters for Linux, v3

stephane eranian wrote:
> On Fri, Dec 12, 2008 at 8:45 PM, Chris Friesen <cfriesen@...tel.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/