Re: [RFC PATCH 0/4] perf/core: Small event scheduling changes

[Frederic Weisbecker]

On Tue, Nov 10, 2009 at 06:13:21AM +0100, Ingo Molnar wrote:
> 
> * Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote:
> 
> > Hi,
> > 
> > This is an rfc patchset, only compile tested just to ensure I'm taking 
> > a good direction before going ahead.
> > 
> > This is intended to rework a bit the perf event scheduling to 
> > guarantee a real priority of the pinned events over the volatile ones. 
> > This patchset handles such priority on task tick time only. But if the 
> > idea is agreed, I could expand that to every task event sched-in calls 
> > to guarantee the priority in every event rescheduling time.
> > 
> > Thanks.
> > 
> > Frederic Weisbecker (4):
> >   perf/core: split context's event group list into pinned and
> >     non-pinned lists
> >   perf/core: Optimize a bit rotate_ctx()
> >   perf/core: Split up pinned and non pinned processing
> >   perf/core: Schedule every pinned events before the the non-pinned
> > 
> >  include/linux/perf_event.h |    3 +-
> >  kernel/perf_event.c        |  283 ++++++++++++++++++++++++++++++++-----------
> >  2 files changed, 212 insertions(+), 74 deletions(-)
> 
> Sans the small naming suggestions i had, the general principle looks 
> good to me - it's a nice restructuring of the various scheduling rules 
> we have for events.
> 
> 	Ingo


Thanks.

With this draft, it makes the pinned priority more consistent
with its purpose but it doesn't yet bring the full pinned over
flexible priority determinism.

It does apply the priority in tick time, while we round robin.
I did that there first so that it covers most of the events
rescheduling actions and also it doesn't bring much more
overhead over the previous layout (in theory), it just changes
the order.

I'll also try to expand the priority constraint each time we
sched in a task: when we schedule a new task that belongs to
a new context, we don't schedule out/in the cpu context but
that will be needed if we want the full priority determinism.

Anyway, I'll do that progressively.

	Frederic.

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