mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stephane Eranian <eranian@hpl.hp.com>
To: "Bryan O'Sullivan" <bos@serpentine.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/6] 2.6.16-rc1 perfmon2 patch for review
Date: Tue, 24 Jan 2006 07:13:25 -0800	[thread overview]
Message-ID: <20060124151325.GC7130@frankl.hpl.hp.com> (raw)
In-Reply-To: <1137774189.28944.47.camel@serpentine.pathscale.com>

Bryan,

On Fri, Jan 20, 2006 at 08:23:09AM -0800, Bryan O'Sullivan wrote:
> 
> > +	if (ctx->ctx_cpu != smp_processor_id()) {
> > +#ifdef __i386__
> > +	/* On IA64 we use smp_call_function_single(), so we
> > +	 * should never be called on the wrong CPU.  On other
> > +	 * archs, that doesn't exist and we use
> > +	 * smp_call_function instead, so silently ignore all
> > +	 * CPUs except the one we care about.
> > +	 */
> 
> This looks grotty.  Can't you add the necessary arch support, instead of
> an i386-specific hack with a misleading comment?  The block should at
> least be "#ifndef __ia64__" to match the comment.
> 

Well, I am not sure why the smp_call_function_single() is not already
implemented for i386. I can see that the underlying function send_IPI_mask()
is there. It also looks like flush_tlb_others() is also selecting CPUs a subset
of CPUs. I am not a big enough expert on x86 to understand if there are gotchas
to watch for. Yet it would surprise me if this is radically different than on
x86_64 (em64t) which already has the call. Maybe someone can clarify this?

> > +		DPRINT(("set_id=%u not found\n", set_id));
> > +error:
> > +		pfm_retflag_set(req->set_flags, PFM_REG_RETFL_EINVAL);
> > +		return -EINVAL;
> > +found:
> > +		if (is_loaded && set == ctx->ctx_active_set)
> > +			goto error;
> 
> I've seen this style of goto usage in the code a few times, and it's
> bizarre.  Why are you jumping backwards to the error exit?  There's
> nothing wrong with using a goto to exit, it's just more usual to have a
> single section at the end of the function that has both the error and
> normal exit paths.

This is not so pretty, I agree. I rewrote the loop differently now.

-- 

-Stephane

  reply	other threads:[~2006-01-24 15:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-20 15:20 Stephane Eranian
2006-01-20 16:23 ` Bryan O'Sullivan
2006-01-24 15:13   ` Stephane Eranian [this message]
2006-01-25 11:10     ` Keith Owens

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=20060124151325.GC7130@frankl.hpl.hp.com \
    --to=eranian@hpl.hp.com \
    --cc=bos@serpentine.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome