All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.