MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <18874.61369.966599.636154@cargo.ozlabs.ibm.com>
Date: Sat, 14 Mar 2009 10:43:53 +1100
From: Paul Mackerras <paulus@samba.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>, linux-kernel@vger.kernel.org,
       Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] perfcounters: Make s/w counters in a group only count
	when group is on
In-Reply-To: <20090313131309.GB10117@elte.hu>
References: <18873.48668.562126.113618@cargo.ozlabs.ibm.com>
	<1236939816.22914.3714.camel@twins>
	<18874.20538.785519.824803@cargo.ozlabs.ibm.com>
	<1236948283.22447.36.camel@twins>
	<1236949440.5188.709.camel@laptop>
	<20090313131309.GB10117@elte.hu>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1987
Lines: 50

Ingo Molnar writes:

> Agreed. There should really be no difference between software 
> and hardware counters as far as the generic perfcounters code 
> goes. It's a magic "metric" that gets read out somehow, and 
> which generates events somehow.

And my patch didn't create any new difference in the core between
software and hardware counters.  It just gave the low-level code a way
to distinguish between sched-out and disable events, and between
sched-in and enable events - for any kind of counter.

That is useful now for making software counters behave correctly, and
will IMO be useful in future for doing lazy PMU switching.

> We can have various grades of hardware versus software counters: 
> 
> - 'pure hardware counters' where both the count and events come 
>   from some hw register
> 
> - 'pure software counters' where both the count and events are 
>   generated by software
> 
> - 'hybride counters' where for example the count might be from a 
>   hardware register, but the event is generated by a hrtimer 
>   (because the hardware is not capable of generating events).
> 
> the is_software_counter() assymetry broke this generally relaxed 
> model of counters.

There are currently two asymmetries that I can see in the core
relating to software vs. hardware groups:

- we don't bother checking with the CPU-specific low-level code
  whether a group with only software counters can go on; we assume it
  always can.

- the exclusive group mechanism only applies to hardware counters,
  since it is there to let the user do funky things with the PMU.

Do you see any other asymmetry?  Note that the patch under discussion
did *not* introduce any additional asymmetry (despite its possibly
ill-chosen title :-).

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/