MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <18791.60479.79841.734481@cargo.ozlabs.ibm.com>
Date: Sat, 10 Jan 2009 11:30:55 +1100
From: Paul Mackerras <paulus@samba.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
       Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 0/9] Performance counters for POWER
In-Reply-To: <1231507715.11687.618.camel@twins>
References: <18791.10652.298501.863657@cargo.ozlabs.ibm.com>
	<1231507715.11687.618.camel@twins>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1465
Lines: 31

Peter Zijlstra writes:

> Hmm, the model I thought would make most sense for power and other
> machines with such heavy constraints was that you'd compose a register
> set when you create groups, and then when you RR the groups, you just
> program the pre-computed sets.

Groups are user-created entities, and in practice (at least so far)
most groups consist of just a single counter.  I don't want to build
in a limitation that you can only count one thing at a time unless you
construct a multi-counter group.  (There is no easy way to combine the
register settings for two groups, short of working out the register
settings for the combined set of events from scratch.)

It would be possible to have an entity that describes a set of groups
(i.e. the result of a scheduling decision) and precompute register
settings for that.  That's the kind of thing I was alluding to when I
talked about major changes to the generic code.  But that entity is a
distinct thing from the current notion of a "group".

> Right, esp on high context switch rates it might dominate the machine.

Currently the constraint check/alternative search seems to take a
fraction of a microsecond, so I'm hopeful it'll be OK.  We'll see.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/