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: <20101005190501.GA21916@elte.hu>
Date:	Tue, 5 Oct 2010 21:05:01 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Hans Rosenfeld <hans.rosenfeld@....com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	"Richter, Robert" <robert.richter@....com>,
	LKML <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Herrmann3, Andreas" <Andreas.Herrmann3@....com>,
	Peter Zijlstra <peterz@...radead.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [RFC 0/3] Basic support for LWP


* Hans Rosenfeld <hans.rosenfeld@....com> wrote:

> But thats not required to use LWP instructions. Maybe Robert will add 
> it to perf some day, or maybe not. It is completely optional, and how 
> it is implemented at some point in the future is completely irrelevant 
> to the basic support of LWP.

It isnt irrelevant. If the concept is implemented in a crappy way, if 
there are random user-space libraries that do not properly expose these 
capabilities and do not allow them to extend existing perf functionality 
in a natural way then we might be better off not adding overhead to the 
scheduler and not enabling it at all.

So thoughts need to be made what the point of it all is and how it 
integrates into perf. If it doesnt integrate, if the whole plan is to 
just get it to user-space where it can be messed up freely in some CPU 
specific way then color me thoroughly uninterested. We have a generic 
instrumentation framework for a reason.

We very much want to know the structure of that area and want to make 
use of it not just on a per task basis. We also want to expose it all in 
a more generalized form.

I cannot believe something like this was committed into silicon without 
at minimum talking to people who have a clue about where it will (and 
should) all go ...

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ