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