public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox