From: Peter Zijlstra <peterz@infradead.org>
To: Stephane Eranian <eranian@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
mingo@elte.hu, "Paul Mackerras" <paulus@samba.org>,
"Frédéric Weisbecker" <fweisbec@gmail.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC] perf_events: ctx_flexible_sched_in() not maximizing PMU utilization
Date: Thu, 06 May 2010 16:20:40 +0200 [thread overview]
Message-ID: <1273155640.5605.300.camel@twins> (raw)
In-Reply-To: <AANLkTikQCkR2K438llKOh43yEgW-Bw7j0f8GoXR50A0V@mail.gmail.com>
On Thu, 2010-05-06 at 16:03 +0200, Stephane Eranian wrote:
> Hi,
>
> Looking at ctx_flexible_sched_in(), the logic is that if group_sched_in()
> fails for a HW group, then no other HW group in the list is even tried.
> I don't understand this restriction. Groups are independent of each other.
> The failure of one group should not block others from being scheduled,
> otherwise you under-utilize the PMU.
>
> What is the reason for this restriction? Can we lift it somehow?
Sure, but it will make scheduling much more expensive. The current
scheme will only ever check the first N events because it stops at the
first that fails, and since you can max fix N events on the PMU its
constant time.
To fix this issue you'd have to basically always iterate all events and
only stop once the PMU is fully booked, which reduces to an O(n) worst
case algorithm.
But yeah, I did think of making the thing an RB-tree and basically
schedule on service received, that should fix the lop-sided RR we get
with constrained events.
next prev parent reply other threads:[~2010-05-06 14:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-06 14:03 [RFC] perf_events: ctx_flexible_sched_in() not maximizing PMU utilization Stephane Eranian
2010-05-06 14:20 ` Peter Zijlstra [this message]
2010-05-06 14:41 ` Stephane Eranian
2010-05-06 15:08 ` Peter Zijlstra
2010-05-06 16:26 ` Stephane Eranian
2010-05-06 17:11 ` Frederic Weisbecker
2010-05-06 17:30 ` Peter Zijlstra
2010-05-07 8:25 ` Peter Zijlstra
2010-05-07 8:44 ` Peter Zijlstra
2010-05-07 9:37 ` Stephane Eranian
2010-05-07 10:06 ` Peter Zijlstra
2010-05-07 10:49 ` Stephane Eranian
2010-05-07 11:15 ` Peter Zijlstra
2010-05-10 9:41 ` Stephane Eranian
2010-05-14 14:55 ` Peter Zijlstra
2010-05-14 15:07 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1273155640.5605.300.camel@twins \
--to=peterz@infradead.org \
--cc=davem@davemloft.net \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox