All of lore.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 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.