From: Borislav Petkov <borislav.petkov@amd.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>,
Ingo Molnar <mingo@elte.hu>, Aristeu Rozanski <aris@redhat.com>,
Randy Dunlap <randy.dunlap@oracle.com>,
Doug Thompson <norsk5@yahoo.com>,
linux-kernel@vger.kernel.org, x86 <x86@kernel.org>
Subject: Re: [PATCH] x86, msr: add support for non-contiguous cpumasks
Date: Fri, 11 Dec 2009 08:30:39 +0100 [thread overview]
Message-ID: <20091211073039.GA21312@aftab> (raw)
In-Reply-To: <4B21A50E.5090801@zytor.com>
On Thu, Dec 10, 2009 at 05:49:02PM -0800, H. Peter Anvin wrote:
> On 12/07/2009 04:21 AM, Borislav Petkov wrote:
> >
> > struct msr {
> > + int cpu;
> > union {
> > struct {
> > u32 l;
>
> I really don't like this patch, for multiple reasons. One of them is
> the above: this has no business being part of struct msr, which reflects
> an MSR value (and ideally should replace at least the use of two
> pointers in other places over time). Having a CPU field and not an MSR
> number field particular doesn't make any sense.
Why, MSRs are per-CPU. My reasoning here is to reflect the value of an
MSR on a particular CPU...
[..]
> The ideal probably would be to use a percpu variable. Now, this would
> either have to be a dynamic percpu allocation (which would have to be
> the responsibility of the caller, and reused, lest this would be a
> *very* expensive proposition), or we would have to make these functions
> run under a mutex. However, as long as the expected callers of this are
> things that get set up once and then pretty much stick around, a percpu
> variable might just work.
I think this would be the cleanest way. Also, best it'll be to allocate
those dynamically only when they're really needed (e.g. on driver
loading) and later reuse them.
[..]
> The third option would be to at least require that the struct msr
> contents are at least serial in the order of the bitmask, not by adding
> another field.
I had that version already done but it seemed half-baked and clumsy for
the MSRs array to traverse. I'll give the percpu variables a shot and
get back to you when I have something ready.
Thanks for reviewing.
--
Regards/Gruss,
Boris.
Operating | Advanced Micro Devices GmbH
System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
Research | Geschäftsführer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni
Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
(OSRC) | Registergericht München, HRB Nr. 43632
next prev parent reply other threads:[~2009-12-11 7:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-07 12:21 [PATCH] x86, msr: add support for non-contiguous cpumasks Borislav Petkov
2009-12-10 7:35 ` Borislav Petkov
2009-12-10 7:38 ` H. Peter Anvin
2009-12-11 1:49 ` H. Peter Anvin
2009-12-11 7:30 ` Borislav Petkov [this message]
2009-12-11 17:14 ` [PATCH v2] " Borislav Petkov
2009-12-11 18:01 ` H. Peter Anvin
2009-12-11 18:36 ` Borislav Petkov
2009-12-11 18:45 ` H. Peter Anvin
2009-12-11 19:02 ` Borislav Petkov
2009-12-11 18:58 ` H. Peter Anvin
2009-12-11 21:30 ` [tip:x86/urgent] x86, msr: Add " tip-bot for Borislav Petkov
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=20091211073039.GA21312@aftab \
--to=borislav.petkov@amd.com \
--cc=aris@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@redhat.com \
--cc=mingo@elte.hu \
--cc=norsk5@yahoo.com \
--cc=randy.dunlap@oracle.com \
--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.