linux-kernel - Re: [RFC v2 2/7] perf: add AUX area to ring buffer for raw data streams

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, 25 Jun 2014 14:09:31 +0300
From:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	Robert Richter <rric@...nel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>,
	Andi Kleen <ak@...ux.intel.com>
Subject: Re: [RFC v2 2/7] perf: add AUX area to ring buffer for raw data streams

Peter Zijlstra <peterz@...radead.org> writes:

> On Wed, Jun 11, 2014 at 06:41:45PM +0300, Alexander Shishkin wrote:
>> +	/*
>> +	 * Set up pmu-private data structures for an AUX area
>> +	 */
>> +	void *(*setup_aux)		(int cpu, void **pages,
>> +					 int nr_pages, bool overwrite);
>> +					/* optional */
>> +
>> +	/*
>> +	 * Free pmu-private AUX data structures
>> +	 */
>> +	void (*free_aux)		(void *aux); /* optional */
>
> I was hoping you could replace those with a PERF_CAP_AUX or something
> and then have one generic allocation routine like you provide in the
> subsequent patches.

I need these to allocate pmu-specific SG tables now, which I don't see
how to generalize nicely. User-visible aux_pages are allocated in the
generic rb_alloc_aux().

As for sg tables, the alternative would be to allocate them in the
event::pmu::add() path, which is probably not very good for
performance, unless I'm missing something? Like, I can allocate stuff in
the first add() and then free it in event::destroy().

Or, we can assume a generic sg table format and allocate them in the
generic code, but then we'll need more capabilities to indicate at least
the size of a table entry. PT needs 64 bits per entry, ARM's TMC needs
32 and the non-SG PT will still need some tables. But I'd rather leave
this part to the pmu drivers. What do you think?

Regards,
--
Alex
--
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/