linux-kernel - round-robining per-cpu counters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 5 May 2009 13:58:42 +1000
From:	Paul Mackerras <paulus@...ba.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Robert Richter <robert.richter@....com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: round-robining per-cpu counters

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/