From: Frederic Weisbecker <fweisbec@gmail.com>
To: Paul Mackerras <paulus@samba.org>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: Re: [PATCH 6/6] perf: Increase round-robin fairness of flexible events
Date: Mon, 11 Jan 2010 02:56:35 +0100 [thread overview]
Message-ID: <20100111015634.GG5039@nowhere> (raw)
In-Reply-To: <20100111003905.GA6066@brick.ozlabs.ibm.com>
On Mon, Jan 11, 2010 at 11:39:05AM +1100, Paul Mackerras wrote:
> On Mon, Jan 11, 2010 at 12:57:59AM +0100, Frederic Weisbecker wrote:
>
> > I think the constraint of "either every or none get
> > scheduled in a group" makes a lot of sense for pinned
> > groups.
> >
> > But I don't see the point in applying this
> > rule inside flexible groups because the nature
> > of flexible events implies these have been created to
> > fight against a limited resource. So if this fight
> > is done only between groups, this is like raising
> > a voluntary starvation.
> >
> > Or..or..May be I just realize too late that the semantic
> > of a group implies that all events inside must be always
> > counted simultaneously? In which case I agree with you,
> > this patch makes no sense and must be dropped.
>
> The original idea of the groups was for situations where you want to
> take the difference or ratio of two counts. For example, if you want
> to measure cache hits but the hardware can only count cache accesses
> and cache misses. In that situation you want to compute accesses
> minus misses, but if the counters for accesses and for misses are
> independently scheduled, statistical fluctuations can mean there is a
> lot of noise in the result, and it might even be negative. Putting
> the two counters into one group means that you can meaningfully
> compute the difference or ratio since the two counter values relate to
> the same set of instructions (even if that isn't the whole execution
> of the program).
>
> The default situation is that each event is in its own group, so the
> starvation you talk about won't arise. If the user has gone to the
> trouble of putting two events into one group, then they are saying
> that they need the events to be scheduled on and off together, and if
> that leads to starvation, that's unfortunate but we can't do any
> better within the limitations of the hardware.
Agreed. This patch came from my misunderstanding of the purpose of
groups.
next prev parent reply other threads:[~2010-01-11 1:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-10 1:38 [PATCH 0/6] perf: Various event scheduling improvements Frederic Weisbecker
2010-01-10 1:38 ` [PATCH 1/6 v2] perf/core: Split context's event group list into pinned and non-pinned lists Frederic Weisbecker
2010-01-10 1:38 ` [PATCH 2/6] list: Introduce list_rotate_left() Frederic Weisbecker
2010-01-10 1:38 ` [PATCH 3/6] perf: Round robin groups of events using list_rotate_left() Frederic Weisbecker
2010-01-14 12:25 ` Peter Zijlstra
2010-01-14 12:29 ` Frederic Weisbecker
2010-01-14 12:32 ` Peter Zijlstra
2010-01-10 1:38 ` [PATCH 4/6] perf: Export software-only event group characteristic as a flag Frederic Weisbecker
2010-01-10 1:38 ` [PATCH 5/6] perf: Don't rotate pinned groups Frederic Weisbecker
2010-01-10 1:38 ` [PATCH 6/6] perf: Increase round-robin fairness of flexible events Frederic Weisbecker
2010-01-10 22:04 ` Paul Mackerras
2010-01-10 23:57 ` Frederic Weisbecker
2010-01-11 0:39 ` Paul Mackerras
2010-01-11 1:56 ` Frederic Weisbecker [this message]
2010-01-14 12:49 ` [PATCH 0/6] perf: Various event scheduling improvements Peter Zijlstra
2010-01-14 13:09 ` Frederic Weisbecker
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=20100111015634.GG5039@nowhere \
--to=fweisbec@gmail.com \
--cc=acme@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--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