[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ED9267F.10106@fb.com>
Date: Fri, 2 Dec 2011 11:26:55 -0800
From: Arun Sharma <asharma@...com>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC: <mingo@...e.hu>, William Cohen <wcohen@...hat.com>,
Stephane Eranian <eranian@...gle.com>,
Vince Weaver <vince@...ter.net>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH 0/6] perf: x86 RDPMC and RDTSC support
On 11/21/11 6:51 AM, Peter Zijlstra wrote:
> These few patches implement x86 RDPMC support and add an extention to the self
> monitoring data to also allow additional time updates using userspace TSC reads.
>
> There's a few loose ends, but it mostly seems to work.
I haven't had a chance to test this out yet. But low overhead, always on
perf counters is something we're very interested in. Thanks for
implementing it.
However, I suspect the major cost of leaving the perf counters always on
seems to be in the hit on context switches, rather than the cost of
reading the perf counters themselves. For eg:
Baseline:
(for i in `seq 1 10`; do numactl --cpunodebind 1 ./lat_ctx -P1 -s32k
4; done) 2>&1 | tee lmbench1.log
1 event:
(for i in `seq 1 10`; do numactl --cpunodebind 1 perf stat -e
instructions ./lat_ctx -P1 -s32k 4; done) 2>&1 | tee lmbench2.log
2 events:
(for i in `seq 1 10`; do numactl --cpunodebind 1 perf stat -e
cycles,instructions ./lat_ctx -P1 -s32k 4; done) 2>&1 | tee lmbench3.log
Baseline: 2.2us
One event: 6.8us
Two events: 7.2us
The cost seems to be at roughly 5us (I measured 2.6.38 and 3.2-rc2).
I'll dig a bit more on what may be going on here.
-Arun
--
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