[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bd4cb8901001210221u5f02f05eq512df5dbb314419b@mail.gmail.com>
Date: Thu, 21 Jan 2010 11:21:19 +0100
From: Stephane Eranian <eranian@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Frederic Weisbecker <fweisbec@...il.com>,
linux-kernel@...r.kernel.org, mingo@...e.hu, paulus@...ba.org,
davem@...emloft.net, perfmon2-devel@...ts.sf.net, eranian@...il.com
Subject: Re: [PATCH] perf_events: improve x86 event scheduling (v5)
On Thu, Jan 21, 2010 at 11:11 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Thu, 2010-01-21 at 11:08 +0100, Stephane Eranian wrote:
>> >> > Do you mean this:
>> >> >
>> >> > hw_perf_group_sched_in_begin(&x86_pmu);
>> >> >
>> >> > for_each_event(event, group) {
>> >> > event->enable(); //do the collection here
>> >> > }
>> >> >
>> >> >
>> >> > if (hw_perf_group_sched_in_end(&x86_pmu)) {
>> >> > rollback...
>> >> > }
>> >> >
>> >> > That requires to know in advance if we have hardware pmu
>> >> > in the list though (can be a flag in the group).
>> >>
>>
>> I don't think this model can work without scheduling for each event.
>>
>> Imagine the situation where you have more events than you have
>> counters. At each tick you:
>
> No it wont indeed, but it will work for where we now use
> hw_perf_group_sched_in() without having to replicate lots of code.
>
> For the cases you mention I see no other way than to try and schedule
> each event individually.
>
Are you suggesting a speculative approach where you first try simply
accumulate then schedule and if this fails, then restart the whole
loop but this time adding and scheduling each event individually?
For groups, you'd have to fail the group if one of its events fails.
--
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