round-robining per-cpu counters

[Paul Mackerras]

It used to be, and as far as I can see still is, the case that per-cpu
counters take priority over per-task counters by virtue of being
scheduled in first.  That is, if you have N hardware counters and >= N
per-cpu counters, then no per-task counters will ever get scheduled
onto the PMU.

That being the case, I don't see what the point of having the
perf_reserved_percpu variable is.  It doesn't do anything except set
cpuctx->max_pertask, which isn't actually used anywhere.  In any case
with the current counter scheduling system there's no need to
"reserve" hardware counters for use by per-cpu counters since any new
per-cpu counters will just bump existing per-task counters off - if
not immediately then the next time that perf_counter_task_tick gets
called.

What was the intended meaning of perf_reserved_percpu?  I presume it
was that there would always be that many hardware counters available
for per-cpu counters regardless of how many per-task counters there
are.  But that doesn't answer the complementary question - how many
hardware counters can we rely on being available for per-task
counters?  At the moment the answer is 0, but I don't think that is a
good answer.

Does anyone have any good ideas about what the scheduling policy
should be?

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