Re: [RFC 0/6] optimize ctx switch with rb-tree

[David Carrillo-Cisneros]

On Wed, Apr 26, 2017 at 3:34 AM, Budankov, Alexey
<alexey.budankov@xxxxxxxxx> wrote:
> Hi David,
>
> I would like to take over on the patches development relying on your help with reviews.

Sounds good.

> Could you provide me with the cumulative patch set to expedite the ramp up?

This RFC is my latest version. I did not have a good solution on how
to solve the problem of handling failure of PMUs that share contexts,
and to activate/inactivate them.

Some things to keep in mind when dealing with task-contexts are:
  1. The number of PMUs is large and growing, iterating over all PMUs
may be expensive (see https://lkml.org/lkml/2017/1/18/859 ).
  2. event_filter_match in this RFC is only used because I did not
find a better ways to filter out events with the rb-tree. It would be
nice if we wouldn't have to check event->cpu != -1 && event->cpu ==
smp_processor_id() and cgroup stuff for every event in task contexts.
  3. I used the inactive events list in this RFC as a cheaper
alternative to threading the rb-tree but it has the problem that
events that are removed due to conflict would be placed at the end of
the list even if didn't run. I cannot recall if that ever happens.
Using this list also causes problem (2.) maybe threading the tree is a
better alternative?
  4. Making the key in task-events to be {PMU,CPU,last_time_scheduled}
(as opposed to {CPU,last_time_scheduled} in the RFC) may simplify
sched in by helping to iterate over all events in same PMU at once,
simplifying the activation/inactivation of the PMU and making it
simple to move to the next PMU on pmu::add errors. The problem with
this approach is to find only the PMUs with inactive events without
traversing a list of all PMUs. Maybe a per-context list of active PMUs
may help (see 1.).

cpu-contexts are much simpler and I think work well with what the RFC
does (they are per-pmu already).

This thread has Peter and Mark's original discussion of the rb-tree
(https://patchwork.kernel.org/patch/9176121/).

Thanks,
David