From: "H. Peter Anvin" <hpa@zytor.com>
To: Borislav Petkov <borislav.petkov@amd.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: Thu, 10 Dec 2009 17:49:02 -0800 [thread overview]
Message-ID: <4B21A50E.5090801@zytor.com> (raw)
In-Reply-To: <20091207122133.GA24877@aftab>
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.
The second is a linear(!!) search executed on every CPU... at the same
time, over the same data structure.
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.
The slightly less radical version would be to simply require an array
that spans the extremes of the CPU numbers in the mask. Even on a
4096-CPU system, we're only talking about 32K worth of memory here.
This is basically the original solution, just accounting for the fact
that the bitmap may be sparse when allocating it.
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.
-hpa
next prev parent reply other threads:[~2009-12-11 1:50 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 [this message]
2009-12-11 7:30 ` Borislav Petkov
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=4B21A50E.5090801@zytor.com \
--to=hpa@zytor.com \
--cc=aris@redhat.com \
--cc=borislav.petkov@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox