public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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