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]

Message-ID: <20140625121156.GA3935@laptop>
Date:	Wed, 25 Jun 2014 14:11:56 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
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

On Wed, Jun 25, 2014 at 02:09:31PM +0300, Alexander Shishkin wrote:
> 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?

Ah, I wasn't aware.. too bad. Maybe add this to the changelog.
--
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/