From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755032AbZEED7g (ORCPT ); Mon, 4 May 2009 23:59:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754204AbZEED7G (ORCPT ); Mon, 4 May 2009 23:59:06 -0400 Received: from bilbo.ozlabs.org ([203.10.76.25]:45384 "EHLO bilbo.ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753773AbZEED7E (ORCPT ); Mon, 4 May 2009 23:59:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18943.47474.963294.862139@drongo.ozlabs.ibm.com> Date: Tue, 5 May 2009 13:58:42 +1000 From: Paul Mackerras To: Ingo Molnar CC: Robert Richter , Peter Zijlstra , Thomas Gleixner , linux-kernel@vger.kernel.org Subject: round-robining per-cpu counters X-Mailer: VM 8.0.12 under 22.3.1 (powerpc-unknown-linux-gnu) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.