linux-kernel - Re: [RFC PATCH] perf_counter: Add support for pinned and exclusive counter groups

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20090114100814.GA23835@elte.hu>
Date:	Wed, 14 Jan 2009 11:08:14 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC PATCH] perf_counter: Add support for pinned and exclusive
	counter groups

* Ingo Molnar <mingo@...e.hu> wrote:

> Yeah. Such artifacts at inheritance stem from the reduction in utility 
> that comes from any exclusive-resource-usage scheme, and are expected.
> 
> For example, right now it works just fine to nest 'timec' in itself 
> [there is a reduction in statistical value if we start round-robining, 
> but there's still full utility]. If it used exclusive or pinned counters 
> that might not work.

for example, this measurement works just fine currently:

aldebaran:~/linux/linux> timec -e 1 timec -e 1 timec -e 1 make -j16 kernel/
 [...]
 Performance counter stats for 'make':

   59561.510176  task clock ticks     (msecs)

    92223201071  instructions         (events)

 Wall-clock time elapsed:  6016.011818 msecs

 Performance counter stats for 'timec':

   59562.300425  task clock ticks     (msecs)

    92223534177  instructions         (events)

 Wall-clock time elapsed:  6017.117985 msecs

 Performance counter stats for 'timec':

   59563.307588  task clock ticks     (msecs)

    92223867295  instructions         (events)

 Wall-clock time elapsed:  6018.590227 msecs

The performance counters are layered upon each other in each nested timec 
instance. In the innermost instance ls runs with 3+3 performance counters 
active at once - and it all just works, without the timec apps having any 
knowledge about each other.

And that is i think what powerful kernel abstractions are about. If we 
provide nice and useful abstractions then the hw folks will eventually 
extend the hw side resources, if users keep bumping into them.

If we structure our design around the limitations then users wont actually 
ever bump into the hw limitations in a clear-cut way - they will bump into 
our design. So they'll pester us, not the hw folks ;-)

Such details are the main difference between the perfmon design and the 
perfcounters design.

	Ingo
--
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/