On Wed, Apr 26, 2017 at 3:34 AM, Budankov, Alexey <alexey.budan...@intel.com> 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
