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

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

Date:	Fri, 12 Dec 2008 10:45:38 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC:	eranian@...il.com, 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

Peter Zijlstra wrote:
> On Fri, 2008-12-12 at 09:59 +0100, stephane eranian wrote:

>>Furthermore, Linux commercial distribution release cycles do not
>>align well with new processor
>>releases. I can boot my RHEL5 kernel on a Nehalem system and it would
>>be  nice not to have to
>>wait for a new kernel update to get the full Nehalem PMU event table,
>>so I can program more than
>>the basic 6 architected events of Intel X86.
> 
> 
> Talking with my community hat on, that is an artificial problem created
> by distributions, tell them to fix it.
> 
> All it requires is a new kernel module that describes the new chip,
> surely that can be shipped as easily as a new library.

I have to confess that I haven't had a chance to look at the code.  Is 
the current proposal set up in such a way as to support loading a module 
and having the new description picked up automatically?


>>Changing the
>>kernel is not an option for
>>many end-users, it may even require re-certifications for many customers.

> What we do care about is technical arguments, and last time I checked,
> hardware resource scheduling was an OS level job.

Here I agree.

> But if the PMU control is critical to the enterprise deployment of
> $customer, then he would have to re-certify on the library update too.

It may not have any basis in fact, but in practice it seems like kernel 
changes are considered more risky than userspace changes.

As you say though, it's not likely that most production systems would be 
running performance monitoring code, so this may only be an issue for 
development machines.


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/