linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 5 May 2009 08:40:51 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	Robert Richter <robert.richter@....com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Mike Galbraith <efault@....de>
Subject: Re: round-robining per-cpu counters


* Paul Mackerras <paulus@...ba.org> wrote:

> 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?

The reservation mechanism really suffered from not being used by 
anything or anyone, and it thus bit-rotted across 300 follow-on 
commits.

What would be the primary usecase? Allow admin to set aside (and 
guarantee) space for task counters? Allow admin to 'force' 
exclusivity of counter ownership?

I think a better general solution would be to have a single 
round-robin list for all currently active counters (both percpu and 
task counters) - and fairly round-robin all of them. The scaling 
information makes it obvious when this is happening.

If admin wants stronger ownership of counters then the 
pinned/exclusive attribute can be used.

We really want to keep the counter-scheduler simple, and we also 
want to make the default to be as permissive as possible.

	Ingo
--
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/