From: Thomas Gleixner <tglx@linutronix.de>
To: eranian@googlemail.com
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
mingo@elte.hu, x86@kernel.org, andi@firstfloor.org,
eranian@gmail.com, sfr@canb.auug.org.au
Subject: Re: [patch 21/24] perfmon: Intel architectural PMU support (x86)
Date: Wed, 26 Nov 2008 15:55:14 +0100 (CET) [thread overview]
Message-ID: <alpine.LFD.2.00.0811261446070.3325@localhost.localdomain> (raw)
In-Reply-To: <492d0c0e.06e2660a.1583.ffffcc0a@mx.google.com>
On Wed, 26 Nov 2008, eranian@googlemail.com wrote:
> +static u64 enable_mask[PFM_MAX_PMCS];
Why do we need enable_mask twice for AMD and Intel ?
> +static u16 max_enable;
> +static int pfm_intel_arch_version;
> +
> +DEFINE_PER_CPU(u64, saved_global_ctrl);
static
> +/*
> + * layout of EAX for CPUID.0xa leaf function
> + */
> +struct pmu_eax {
> + unsigned int version:8; /* architectural perfmon version */
> + unsigned int num_cnt:8; /* number of generic counters */
> + unsigned int cnt_width:8; /* width of generic counters */
> + unsigned int ebx_length:8; /* number of architected events */
> +};
in arch/x86/include/asm/intel_arch_perfmon.h we have already:
union cpuid10_eax {
struct {
unsigned int version_id:8;
unsigned int num_counters:8;
unsigned int bit_width:8;
unsigned int mask_length:8;
} split;
unsigned int full;
};
Can we either use this or remove it ?
> +/*
> + * layout of EDX for CPUID.0xa leaf function when perfmon v2 is detected
> + */
> +struct pmu_edx {
> + unsigned int num_cnt:5; /* number of fixed counters */
> + unsigned int cnt_width:8; /* width of fixed counters */
> + unsigned int reserved:19;
> +};
> +static void pfm_intel_arch_acquire_pmu_percpu(void);
> +static void pfm_intel_arch_release_pmu_percpu(void);
> +static int pfm_intel_arch_stop_save(struct pfm_context *ctx,
> + struct pfm_event_set *set);
> +static int pfm_intel_arch_has_ovfls(struct pfm_context *ctx);
> +static void __kprobes pfm_intel_arch_quiesce(void);
> +
> +/*
> + * physical addresses of MSR controlling the perfevtsel and counter registers
> + */
> +struct pfm_arch_pmu_info pfm_intel_arch_pmu_info = {
> + .stop_save = pfm_intel_arch_stop_save,
> + .has_ovfls = pfm_intel_arch_has_ovfls,
> + .quiesce = pfm_intel_arch_quiesce,
> + .acquire_pmu_percpu = pfm_intel_arch_acquire_pmu_percpu,
> + .release_pmu_percpu = pfm_intel_arch_release_pmu_percpu
> +};
A) static
B) Please move it to the bottom to avoid all the forward declarations.
> +static void pfm_intel_arch_check_errata(void)
__init ?
> +static void pfm_intel_arch_setup_generic(unsigned int version,
Ditto.
> +static void pfm_intel_arch_setup_fixed(unsigned int version,
Ditto.
> +static int pfm_intel_arch_probe_pmu(void)
Ditto.
> + /*
> + * handle version new anythread bit (bit 2)
> + */
-ENOPARSE
> + if (version == 3)
> + rsvd = 1ULL << 3;
This sets bit 3
> + else
> + rsvd = 3ULL << 2;
And this sets bit 2 and 3.
> +static int pfm_intel_arch_stop_save(struct pfm_context *ctx,
> + struct pfm_event_set *set)
> +{
> + u64 used_mask[PFM_PMC_BV];
> + u64 val, wmask, ovfl_mask;
> + u32 i, count;
> +
> + wmask = 1ULL << pfm_pmu_conf->counter_width;
> +
> + pfm_arch_bv_and(used_mask,
> + set->used_pmcs,
> + enable_mask,
> + max_enable);
> +
> + count = pfm_arch_bv_weight(used_mask, max_enable);
So we have:
set->used_pmcs and enable_mask and max_enable.
Why can set->used_pmcs contain bits which are not in the enable_mask
in the first place ? Why does the arch code not tell the generic code
which pmcs are available so we can avoid all this mask, weight
whatever magic ?
We store the same information in slightly different incarnations in
various places and then we need to mingle them all together to get to
the real data. That makes no sense at all.
> + /*
> + * stop monitoring
> + * Unfortunately, this is very expensive!
> + * wrmsrl() is serializing.
> + */
> + for (i = 0; count; i++) {
> + if (pfm_arch_bv_test_bit(i, used_mask)) {
> + wrmsrl(pfm_pmu_conf->pmc_desc[i].hw_addr, 0);
> + count--;
> + }
> + }
> +
> + /*
> + * if we already having a pending overflow condition, we simply
> + * return to take care of this first.
> + */
> + if (set->npend_ovfls)
> + return 1;
Why are the counters enabled at all when an overflow is pending, which
stopped the counters anyway ?
Thanks,
tglx
next prev parent reply other threads:[~2008-11-26 14:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-26 8:42 eranian
2008-11-26 14:55 ` Thomas Gleixner [this message]
2008-11-26 15:45 ` stephane eranian
2008-11-26 16:10 ` Thomas Gleixner
2008-11-26 16:45 ` Andi Kleen
2008-12-02 3:09 ` stephane eranian
-- strict thread matches above, loose matches on Subject: below --
2008-11-25 21:36 eranian
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=alpine.LFD.2.00.0811261446070.3325@localhost.localdomain \
--to=tglx@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=eranian@gmail.com \
--cc=eranian@googlemail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sfr@canb.auug.org.au \
--cc=x86@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 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®