From: Peter Zijlstra <peterz@infradead.org>
To: "Liang, Kan" <kan.liang@intel.com>
Cc: "andi@firstfloor.org" <andi@firstfloor.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH V5 1/2] perf ignore LBR and extra_regs
Date: Mon, 14 Jul 2014 18:28:33 +0200 [thread overview]
Message-ID: <20140714162833.GF9918@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F077014E1D5E@SHSMSX103.ccr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]
so once more; and then I'm going to route your emails to /dev/null, wrap
text at 78 chars.
On Mon, Jul 14, 2014 at 02:28:36PM +0000, Liang, Kan wrote:
> > > +++ b/arch/x86/kernel/cpu/perf_event.h
> > > @@ -464,6 +464,12 @@ struct x86_pmu {
> > > */
> > > struct extra_reg *extra_regs;
> > > unsigned int er_flags;
> > > + /*
> > > + * EXTRA REG MSR can be accessed
> > > + * The extra registers are completely unrelated to each other.
> > > + * So it needs a flag for each extra register.
> > > + */
> > > + bool extra_msr_access[EXTRA_REG_MAX];
> >
> > So why not in struct extra_reg again? You didn't give a straight answer there.
>
> I think I did in the email.
> You mentioned that there's still (only) 4 empty bytes at the tail of
> extra_reg itself. However, the extra_reg_type may be extended in the
> near future. So that may not be a reason to move to extra_reg.
Well, you can always grow. Also be explicit, 'may be' is an empty
statement.
> Furthermore, if we move extra_msr_access to extra_reg, I guess we have
> to modify all the related micros (i.e EVENT_EXTRA_REG) to initialize
> the new items. That could be a big change.
Nah, trivial stuff :-)
> On the other side, in x86_pmu structure, there are extra_regs related
> items defined under the comments "Extra registers for events". And
> the bit holes are enough for current usage and future extension.
>
> So I guess x86_pmu should be a good place to store the availability
> of the reg.
It just doesn't make sense to me to have multiple arrays of the same
thing.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-07-14 16:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-10 10:59 [PATCH V5 1/2] perf ignore LBR and extra_regs kan.liang
2014-07-10 10:59 ` [PATCH V5 2/2] kvm: ignore LBR and extra_reg kan.liang
2014-07-14 10:53 ` [PATCH V5 1/2] perf ignore LBR and extra_regs Peter Zijlstra
2014-07-14 14:28 ` Liang, Kan
2014-07-14 16:28 ` Peter Zijlstra [this message]
2014-07-14 11:08 ` Peter Zijlstra
2014-07-14 11:55 ` Paolo Bonzini
2014-07-14 12:09 ` Peter Zijlstra
2014-07-14 12:40 ` Paolo Bonzini
2014-07-14 12:48 ` Peter Zijlstra
2014-07-14 13:47 ` Paolo Bonzini
2014-07-14 13:36 ` Liang, Kan
2014-07-14 13:40 ` Paolo Bonzini
2014-07-14 13:44 ` Liang, Kan
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=20140714162833.GF9918@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=andi@firstfloor.org \
--cc=kan.liang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.