Message-ID: <20140227120723.GH6945@e106331-lin.cambridge.arm.com>
Date:	Thu, 27 Feb 2014 12:07:23 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Will Deacon <Will.Deacon@....com>,
	Dave P Martin <Dave.Martin@....com>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH 4/7] perf: be less pessimistic when scheduling events

On Tue, Feb 25, 2014 at 11:29:36AM +0000, Peter Zijlstra wrote:
> On Tue, Feb 11, 2014 at 05:48:05PM +0000, Mark Rutland wrote:
> > On Mon, Feb 10, 2014 at 05:58:54PM +0000, Peter Zijlstra wrote:
> > > On Mon, Feb 10, 2014 at 05:44:21PM +0000, Mark Rutland wrote:
> > > > This patch makes ctx_flexible_sched_in attempt to schedule every group
> > > > in the flexible_groups list even when earlier groups failed to schedule,
> > > > enabling more groups to be scheduled simultaneously.
> > > 
> > > Since you're basically free to create as many events as you want, you can
> > > (as an unprivilidged user) make the context switch to and from your task
> > > arbitrarily expensive.
> > 
> > Not that it makes the approach any better, but surely this is already
> > the case for software events? 
> 
> Yeah, software events are a problem; I realized this the moment I send
> that email. However, software events do not have the O(n!) programming
> fail hw events have.
> 
> AMD Fam15h has a O(n^4) termination of the O(n*n!) algorithm, the rest
> of x86 has a normal O(n^2) bound.

Ok. I hadn't realised how expensive the event constraint solving was for
other architectures. For us it's a simple bitmap test at present.

> > I can create as many as I want, and they'll always try to schedule.
> > 
> > I'll take a look into other ways to stop disparate PMUs' events from
> > adversely affecting each other. I guess it might not be possible to
> > solve the general problem without allowing said expensive context
> > switch.
> 
> So the problem you're facing is that you'll attach events for each PMU
> available on the system to a particular task? And simply want to
> continue scheduling even though a particular event will never fit on the
> CPUs PMU its currently running on?

Basically, though s/fit on/be sane for/.

> So the trivial work-around would be to create an event per cpu and set
> event->cpu. That way you'll get the event_filter_match() exception in
> ctx_flexible_sched_in() and we'll skip over all events that cannot be
> programmed on this CPU.

While that's trivial for the core, it's painful elsewhere. Either
userspace has to figure out that it's on a heterogeneous system and
create the additional events, or when initialising events we need to
create the set of cpu-specific events transparently, avoiding recursion
in the initialisation code.

> The other approach is adding a cpumask to events, which would
> drastically cut down on the amount of events you'd need to create; then
> again, ARM doesn't have a silly amount of CPUs x86 has just quite yet.

This sounds good, though with a slight alteration becomes better: with a
pmu-specific filter function we could reuse the cpumask we use in the
arch backend. No changes to events, just an additional (optional)
callback on struct pmu.

Thanks for the suggestions.

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

Powered by blists - more mailing lists