From: Stephane Eranian <eranian@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: eranian@gmail.com, linux-kernel@vger.kernel.org, mingo@elte.hu,
paulus@samba.org, davem@davemloft.net, fweisbec@gmail.com,
perfmon2-devel@lists.sf.net
Subject: [BUG] perf_events: ctx_flexible_sched_in()
Date: Mon, 1 Feb 2010 13:20:34 +0100 [thread overview]
Message-ID: <bd4cb8901002010420o2ea7dbafnba84f78b6a2f38f5@mail.gmail.com> (raw)
Hi,
I believe there is something wrong with ctx_flexible_sched_in().
The function does not allow maximizing PMU usage because of
the way can_add_hw is managed. Basically, as soon as a group
fail to be scheduled in, then no other group can. I believe this
is not optimum. You need to skip the group that fails and keep
scanning the list. There may be other groups which can be
scheduled.
Here is an example to illustrate the issue:
$ task -ebaclears,div,instructions_retired,fp_assist noploop 5
noploop for 5 seconds
908 baclears (scaled from 74.97% of time)
0 div (scaled from 50.01% of time)
11328128990 instructions_retired (scaled from 74.99% of time)
0 fp_assist (scaled from 50.00% of time)
Here div, fp_assist can only go on counter 1. There is no explicit
grouping. On Intel Core, you have 2 generic, 3 fixed counters.
Instruction_retired can go on a fixed counter. Thus, I was
expecting baclears and instructions_retired to always be scheduled.
The other two would alternate at 50% each. While you get the latter
behavior, you are not getting full utilization for the other two.
Once I modify ctx_flexible_sched_in():
$ ./task -ebaclears,div,instructions_retired,fp_assist noploop 5
noploop for 5 seconds
658 baclears
0 div (scaled from 50.01% of time)
11726844342 instructions_retired
0 fp_assist (scaled from 50.00% of time)
I get the right result. Thus, I think, we need to drop can_add_hw
from ctx_flexible_sched_in().
Am I missing something in the role of can_add_hw?
If not, then I I will provide a patch to get the optimum behavior.
next reply other threads:[~2010-02-01 12:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-01 12:20 Stephane Eranian [this message]
2010-02-01 12:27 ` 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=bd4cb8901002010420o2ea7dbafnba84f78b6a2f38f5@mail.gmail.com \
--to=eranian@google.com \
--cc=davem@davemloft.net \
--cc=eranian@gmail.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=perfmon2-devel@lists.sf.net \
--cc=peterz@infradead.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
Powered by JetHome