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
next prev parent 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 [PATCH 2/6] 2.6.16-rc1 perfmon2 patch for review 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 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.