[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7c86c4470906230240g7d748708s7b7b8af141c53c0c@mail.gmail.com>
Date: Tue, 23 Jun 2009 11:40:55 +0200
From: stephane eranian <eranian@...glemail.com>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Yong Wang <yong.y.wang@...ux.intel.com>,
"Wang, Yong Y" <yong.y.wang@...el.com>,
Ingo Molnar <mingo@...e.hu>,
LKML <linux-kernel@...r.kernel.org>,
Paul Mackerras <paulus@...ba.org>,
Andi Kleen <andi@...stfloor.org>
Subject: Re: perf_counter Atom patch
On Tue, Jun 23, 2009 at 11:10 AM, Peter Zijlstra<a.p.zijlstra@...llo.nl> wrote:
> On Tue, 2009-06-23 at 16:34 +0800, Yong Wang wrote:
>> > you could simply consider having 0 fixed counters and everything else would work
>> > as expected. But there is a catch, unfortunately, in that there is erratum AE49
>> > which says that there is only one enable bit to control the two generic counters
>> > on Core Duo/Solo.
>
> Ah, that's similar to P6 like machines. The P6 docs say that to disable
> a counter you should simply write all zeros (except the EN bit for ctr0)
> to the control register (IIRC).
>
> I suppose we could do something similar on these errata cores, make
> x86_pmu_disable_counter() write ARCH_PERFMON_EVENTSEL0_ENABLE instead.
>
> Would that work?
>
I suspect that to make this work correctly on P6 and Core Duo, you
will have to enforce
only one event/group to maintain the independence you expose at the
user level. An
Alternative would be to ensure that:
- group leader in always in counter0
- sibling events are created with disabled=0
- ioctl(ENABLE/DISABLE) on siblings always fail
Of course, this does not work, if the group leader event requires
counter1. But I have to check
if such restriction exists on Core Duo.
--
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