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
| ||
|
Date: Mon, 11 Jan 2010 11:39:05 +1100 From: Paul Mackerras <paulus@...ba.org> To: Frederic Weisbecker <fweisbec@...il.com> Cc: Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>, Peter Zijlstra <peterz@...radead.org>, Arnaldo Carvalho de Melo <acme@...hat.com> Subject: Re: [PATCH 6/6] perf: Increase round-robin fairness of flexible events On Mon, Jan 11, 2010 at 12:57:59AM +0100, Frederic Weisbecker wrote: > I think the constraint of "either every or none get > scheduled in a group" makes a lot of sense for pinned > groups. > > But I don't see the point in applying this > rule inside flexible groups because the nature > of flexible events implies these have been created to > fight against a limited resource. So if this fight > is done only between groups, this is like raising > a voluntary starvation. > > Or..or..May be I just realize too late that the semantic > of a group implies that all events inside must be always > counted simultaneously? In which case I agree with you, > this patch makes no sense and must be dropped. The original idea of the groups was for situations where you want to take the difference or ratio of two counts. For example, if you want to measure cache hits but the hardware can only count cache accesses and cache misses. In that situation you want to compute accesses minus misses, but if the counters for accesses and for misses are independently scheduled, statistical fluctuations can mean there is a lot of noise in the result, and it might even be negative. Putting the two counters into one group means that you can meaningfully compute the difference or ratio since the two counter values relate to the same set of instructions (even if that isn't the whole execution of the program). The default situation is that each event is in its own group, so the starvation you talk about won't arise. If the user has gone to the trouble of putting two events into one group, then they are saying that they need the events to be scheduled on and off together, and if that leads to starvation, that's unfortunate but we can't do any better within the limitations of the hardware. 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/
Powered by blists - more mailing lists