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]
Message-ID: <20140217144436.GS27965@twins.programming.kicks-ass.net>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ