linux-kernel - Re: [RFC 0/3] Basic support for LWP

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:	Wed, 6 Oct 2010 09:35:58 +0200
From:	Robert Richter <robert.richter@....com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	"Rosenfeld, Hans" <Hans.Rosenfeld@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	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>,
	Stephane Eranian <eranian@...glemail.com>
Subject: Re: [RFC 0/3] Basic support for LWP

On 05.10.10 15:05:01, Ingo Molnar wrote:

> 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.

I was looking at how this integrates into the perf syscall. It might
be a little disappointing, but there is not much to do for the kernel.
Ring buffer handling is implemented in hardware now, the user land
sets up address ranges in the task's address space for buffers and
thus may direct access it. We do not need an interrupt handler to fill
the buffers. The pmu state is saved and restored during context
switches in ways that has been proven for the fpu (xsave) and
virtualization (VMCB like LWPCB). So, overall hardware is now doing
the job for writing samples into a userland buffer and managing the
pmu state. This reduces system overhead while profiling a lot
especially because we don't have to walk through a software stack with
each sample (this is where the 'lightweight' comes from).

Of course this does not fit into current frameworks because of its
difference in concept, but in general we want to see it in perf. So
the main work of integration will leave here to tool and library
implementation. But for this Linux must implement LWP context switch
support. This is what Hans did.

We also measured the system impact which comes from the additional
rdmsrl() if the cpu supports LWP. There is no significant performance
decrease in a worst case scenario. So, this is how we think it is the
best to implement it and we need your feedback here.

I think we should consider to apply patch 1/3 as it is unrelated to
LWP and reworks and improves the code.

Thanks,

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

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