From: Andi Kleen <andi@firstfloor.org>
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 05/24] perfmon: X86 generic code (x86)
Date: Wed, 26 Nov 2008 12:33:09 +0100 [thread overview]
Message-ID: <20081126113309.GS6703@one.firstfloor.org> (raw)
In-Reply-To: <492d0be1.09cc660a.0b75.44b7@mx.google.com>
On Wed, Nov 26, 2008 at 12:42:09AM -0800, eranian@googlemail.com wrote:
> + * set cannot be NULL. Context is locked. Interrupts are masked.
> + *
> + * Caller has already restored all PMD and PMC registers, if
> + * necessary (i.e., lazy restore scheme).
> + *
> + * On x86, the only common code just needs to unsecure RDPMC if necessary
What is insecure about RDPMC? (except perhaps when secure
computing mode is on)
I think it should be enabled by default BTW because on Core2+ you
can always read the fixed counters with it.
> + */
> + if (using_nmi)
> + iip = __get_cpu_var(real_iip);
Call it real_rip perhaps?
> + /*
> + * only NMI related calls
> + */
> + if (val != DIE_NMI_IPI)
> + return NOTIFY_DONE;
> +
> + /*
> + * perfmon not using NMI
> + */
> + if (!__get_cpu_var(pfm_using_nmi))
> + return NOTIFY_DONE;
It should not register in this case. die notifiers are costly
because they make a lot of exceptions slower.
> + /*
> + * we need to register our NMI handler when the kernels boots
> + * to avoid a deadlock condition with the NMI watchdog or Oprofile
What deadlock?
> + * if we were to try and register/unregister on-demand.
> + */
> + register_die_notifier(&pfm_nmi_nb);
> + return 0;
> +
> +/*
> + * arch-specific user visible interface definitions
> + */
> +
> +#define PFM_ARCH_MAX_PMCS (256+64) /* 256 HW 64 SW */
> +#define PFM_ARCH_MAX_PMDS (256+64) /* 256 HW 64 SW */
A little excessive for current x86s?
> +#define _ASM_X86_PERFMON_KERN_H_
> +
> +#ifdef CONFIG_PERFMON
> +#include <linux/unistd.h>
> +#ifdef CONFIG_4KSTACKS
> +#define PFM_ARCH_STK_ARG 8
> +#else
> +#define PFM_ARCH_STK_ARG 16
> +#endif
Very fancy. But is it really worth it?
> + * bits as this may cause crash on some processors.
> + */
> + if (pfm_pmu_conf->pmd_desc[cnum].type & PFM_REG_C64)
> + value = (value | ~pfm_pmu_conf->ovfl_mask)
> + & ~pfm_pmu_conf->pmd_desc[cnum].rsvd_msk;
> +
> + PFM_DBG_ovfl("pfm_arch_write_pmd(0x%lx, 0x%Lx)",
> + pfm_pmu_conf->pmd_desc[cnum].hw_addr,
> + (unsigned long long) value);
> +
> + wrmsrl(pfm_pmu_conf->pmd_desc[cnum].hw_addr, value);
Not sure how well error handling would fit in here, but it's
normally a good idea to make at least the first wrmsrl to
these counters a checking_wrmsrl because sometimes simulators
or hypervisors don't implement them.
> + */
> +static inline void pfm_arch_unload_context(struct pfm_context *ctx)
In general a lot of these inlines seem rather large. If they are
called more than once consider out of lining for better code size.
> + * x86 does not need extra alignment requirements for the sampling buffer
> + */
> +#define PFM_ARCH_SMPL_ALIGN_SIZE 0
> +
> +asmlinkage void pmu_interrupt(void);
> +
> +static inline void pfm_arch_bv_copy(u64 *a, u64 *b, int nbits)
All these bitmap wrappers just seem like unnecessary obfuscation.
Could you just drop them and call the standard functions directly?
-Andi
--
ak@linux.intel.com
next prev parent reply other threads:[~2008-11-26 11:22 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-26 8:42 [patch 05/24] perfmon: X86 generic code (x86) eranian
2008-11-26 11:33 ` Andi Kleen [this message]
2008-11-26 12:05 ` Stephen Rothwell
2008-11-26 12:22 ` Andi Kleen
2008-11-26 12:48 ` Stephen Rothwell
2008-11-26 13:32 ` Thomas Gleixner
2008-11-26 13:56 ` stephane eranian
2008-11-26 16:38 ` Thomas Gleixner
2008-11-27 9:51 ` stephane eranian
2008-11-27 10:56 ` Thomas Gleixner
2008-11-27 11:37 ` David Miller
2008-11-27 14:40 ` Thomas Gleixner
2008-11-26 13:35 ` Thomas Gleixner
2008-11-26 14:00 ` Andi Kleen
2008-11-26 21:18 ` Thomas Gleixner
2008-11-26 21:37 ` stephane eranian
2008-11-26 23:16 ` Thomas Gleixner
2008-11-27 9:38 ` stephane eranian
2008-11-26 22:54 ` Thomas Gleixner
2008-11-27 10:06 ` Andi Kleen
2008-11-27 10:09 ` stephane eranian
2008-11-27 10:29 ` Thomas Gleixner
2008-11-27 11:31 ` Andi Kleen
2008-11-27 11:35 ` stephane eranian
2008-11-27 11:42 ` David Miller
2008-11-27 11:49 ` Thomas Gleixner
2008-11-27 12:38 ` Andi Kleen
2008-11-27 12:31 ` stephane eranian
2008-11-27 12:46 ` Andi Kleen
2008-11-27 13:32 ` Thomas Gleixner
2008-11-27 13:37 ` stephane eranian
2008-11-27 13:51 ` Andi Kleen
2008-11-27 13:50 ` Andi Kleen
2008-11-27 11:52 ` Peter Zijlstra
2008-11-27 12:04 ` stephane eranian
2008-11-27 12:16 ` Peter Zijlstra
2008-11-27 12:32 ` Andi Kleen
2008-11-27 12:28 ` stephane eranian
2008-11-27 12:45 ` Andi Kleen
2008-11-27 13:30 ` stephane eranian
2008-11-27 13:49 ` Andi Kleen
2008-11-27 13:47 ` 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=20081126113309.GS6703@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=akpm@linux-foundation.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