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
Date: Sat, 14 Mar 2009 10:43:53 +1100 [thread overview]
Message-ID: <18874.61369.966599.636154@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <20090313131309.GB10117@elte.hu>
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.
next prev parent reply other threads:[~2009-03-13 23:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-13 1:59 Paul Mackerras
2009-03-13 10:23 ` Peter Zijlstra
2009-03-13 12:23 ` Paul Mackerras
2009-03-13 12:44 ` Peter Zijlstra
2009-03-13 13:04 ` Peter Zijlstra
2009-03-13 13:13 ` Ingo Molnar
2009-03-13 23:43 ` Paul Mackerras [this message]
2009-03-13 22:41 ` Paul Mackerras
2009-03-14 11:51 ` Ingo Molnar
2009-03-16 9:56 ` Peter Zijlstra
2009-03-16 10:33 ` Paul Mackerras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18874.61369.966599.636154@cargo.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®