linux-kernel - Re: [PATCH 4/4] perf, x86: Fix event scheduler to solve complex scheduling problems

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: <20110417084432.GM31407@erda.amd.com>
Date:	Sun, 17 Apr 2011 10:44:32 +0200
From:	Robert Richter <robert.richter@....com>
To:	Stephane Eranian <eranian@...gle.com>
CC:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] perf, x86: Fix event scheduler to solve complex
 scheduling problems

On 16.04.11 11:52:54, Stephane Eranian wrote:
> On Fri, Apr 15, 2011 at 5:27 PM, Robert Richter <robert.richter@....com> wrote:

> >        event code      counter         failure         possible solution
> >
> > 1)      0x043           PMC[2:0]        0               1
> >        0x02E           PMC[3,0]        3               0
> >        0x003           PMC3            FAIL            3
> >
> I am not sure I understand this failure case. If I recall
> the scheduler looks at the weight of each event first:
> 
>                                             weight
> 1)      0x043           PMC[2:0]  3
>         0x02E           PMC[3,0]   2
>         0x003           PMC3        1
> 
> Then, it schedules in increasing weight order. So it will
> schedule weight 1, 2, 3. For weight 1, it will find counter3,
> for weight 2, it will take counter0, for  weight 3, it will
> take counter 1 given 0 is already used.
> 
> Or am I reading your example the wrong way?

No, I have to admit this one was taken out of my mind and I picked
a wrong example for the special problem I was thinking about. The
above works as you described because of the constraint's weights.

I don't have an example with existing constraints, but consider the
following (theoretical) one:

counter: 3210		Failure:	Solution:

e1	   xx		  xo		  ox
e2	  xx 		 xo		 ox
e3	 x x 		o x		o x
e4	 x  x		x  F		x  o

The special with the above is that two events (e1 and e2) must be
rescheduled to schedule e4. This means that swapping counters of only
one already scheduled event is not sufficient. A counter of a third
event must be freed, this counter is then taken by the second event.

> The fact that counter have overlapping constraints
> should not matter. In fact this is what happens with
> counters without constraints.

An event set containing constraints with following conditions is
problematic:

 (c1->weight <= c2->weight && (c1->cmask & c2->cmask != c1->cmask))

Basically this means both constraints do not overlap completly. You
can't select then the correct counter without knowing the events with
higher weights that will be scheduled later.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

--
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/