linux-kernel - Re: [PATCH 6/6] perf: Increase round-robin fairness of flexible events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100110235758.GC5039@nowhere>
Date:	Mon, 11 Jan 2010 00:57:59 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH 6/6] perf: Increase round-robin fairness of flexible
	events

On Mon, Jan 11, 2010 at 09:04:40AM +1100, Paul Mackerras wrote:
> Frederic,
> 
> Nice to see someone working on the event scheduling in perf.
> 
> But I don't think this patch makes sense:
> 
> > Group of flexible events are round-robined in each tick so that
> > each group has its chance to be scheduled. But the fairness
> > per group granularity doesn't propagate inside the groups
> > themselves.
> > 
> > If only the first events of each groups have a chance to make
> > their way, the remaining ones will never be scheduled.
> > 
> > Hence this patch propagates the round-robin to the events
> > inside the groups.
> 
> The semantic of a group is that either all of the events in the group
> are scheduled in, or none of them are.  So it doesn't make sense to
> talk about fairness within a group, and I don't see any point to
> rotating the elements of the sibling_list.  Or have I misunderstood
> what you're aiming at?

You're right. I forgot that a group that is only partially scheduled will
have its scheduled events cancelled.

But is it a sane behaviour considering the nature on non-pinned events?

Let's take an example. In x86 we have 4 breakpoint registers available.

We have 3 pinned breakpoint events in one group, and say, 2 groups
of flexible breakpoints:

 Pinned          Flexible0         Flexible1
   |                |                 |
  Bp1              Bp4               Bp6
  Bp2              Bp5               Bp7
  Bp3

The flexible ones will never get scheduled because
we only have 4 available slots and we need 5. And if
we try to schedule Flexible0, Bp4 will make it, but
not Bp5, so Bp4 get cancelled, and so on.

But the semantics of non-pinned counters is about
time-sharing them.

If we don't cancel partially-only scheduled flexible
groups and if we round robin inside flexible groups,
then these will all make it.

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/