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] [day] [month] [year] [list]

Date:	Tue, 5 May 2009 15:49:43 +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:

> > 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.
> 
> Sounds good, but I'm having trouble visualizing how we combine a 
> fairly static set of per-cpu counters with several sets of 
> per-task counters that come and go as their tasks get scheduled in 
> and out. Is there some clever scheduling technique that sorts all 
> that out?

Fair scheduling techniques would import the complexity of 
kernel/sched*.c into kernel/perf_counter.c - not sure we want that 
(at this stage at least).

So i'd go for the second best option: the simplest one.

One simple option would be to 'interleave' the two lists on sched-in 
(take a counter from one list, then from the other, then from the 
first, etc.), combined with the alternate rotation of both lists.

Another, perhaps even simpler option would be to do the alternation 
on a per list basis: rotate which of the two lists go first on 
sched-in, from the task tick.

Can you see any showstopper artifacts in this scheme?

Later on, if anyone finds this method lacking it can be improved 
gradually either by making the accounting/statistics smarter, or by 
increasing the frequency of rotation events and coupling it not to 
the scheduler tick but to a counter perhaps.

	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/