linux-kernel - Re: [PATCH v1 07/11] x86: perf: intel

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 17 Feb 2014 15:44:36 +0100
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,
	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>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Matt Fleming <matt.fleming@...el.com>
Subject: Re: [PATCH v1 07/11] x86: perf: intel_pt: Intel PT PMU driver

On Thu, Feb 06, 2014 at 12:50:30PM +0200, Alexander Shishkin wrote:
> +static int topa_insert_pages(struct pt_buffer *buf, gfp_t gfp,
> +			     enum topa_sz sz)
> +{
> +	struct topa *topa = buf->last;
> +	int node = cpu_to_node(buf->cpu);
> +	int order = get_order(sizes(sz));
> +	struct page *p;
> +	unsigned long pn;
> +
> +	p = alloc_pages_node(node, gfp | GFP_USER | __GFP_ZERO | __GFP_NOWARN | __GFP_NORETRY, order);
> +	if (!p)
> +		return -ENOMEM;

> +
> +	return 0;
> +}
> +
> +static int pt_buffer_init_topa(struct pt_buffer *buf, size_t size, gfp_t gfp)
> +{
> +	struct topa *topa;
> +	int err, region_size;
> +
> +	topa = topa_alloc(buf->cpu, gfp);
> +	if (!topa)
> +		return -ENOMEM;
> +
> +	topa_insert_table(buf, topa);
> +
> +	region_size = pt_get_topa_region_size(buf->snapshot, size);
> +	if (region_size < 0) {
> +		pt_buffer_fini_topa(buf);
> +		return region_size;
> +	}
> +
> +	while (region_size && get_order(sizes(region_size)) > MAX_ORDER)
> +		region_size--;
> +
> +	/* fixup watermark in case of higher order allocations */
> +	if (buf->watermark < (sizes(region_size) >> PAGE_SHIFT))
> +		buf->watermark = sizes(region_size) >> PAGE_SHIFT;
> +
> +	while (buf->size < size) {
> +		err = topa_insert_pages(buf, gfp, region_size);
> +		if (err) {
> +			if (region_size) {
> +				region_size--;
> +				continue;
> +			}
> +			pt_buffer_fini_topa(buf);
> +			return -ENOMEM;
> +		}
> +	}

So MAX_ORDER is 11, which gives us (11+12) 23bit or 8M max allocations, right?

Given this TOPA stuff is completely fucked in the first release, that's
about all we can get it, right?

Now given you said 100s MB/s data rate for this itrace stuff, we're at
~0.1s traces. And that's in the very best case where we can actually get
8M.

Is that a workable amount?

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