From: Andi Kleen <ak@suse.de>
To: Christoph Lameter <clameter@sgi.com>
Cc: virtualization@lists.osdl.org,
Jeremy Fitzhardinge <jeremy@goop.org>,
akpm@osdl.org, xen-devel@lists.xensource.com,
Chris Wright <chrisw@sous-sol.org>,
Ian Pratt <ian.pratt@xensource.com>,
linux-kernel@vger.kernel.org
Subject: Re: [patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor.
Date: Thu, 3 Aug 2006 07:39:13 +0200 [thread overview]
Message-ID: <200608030739.13334.ak@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0608022227210.27356@schroedinger.engr.sgi.com>
On Thursday 03 August 2006 07:32, Christoph Lameter wrote:
> On Thu, 3 Aug 2006, Andi Kleen wrote:
>
> > > As far as I can tell from this conversation there are special "Xen"
> > > drivers that need this not the rest of the system.
> >
> > Yes, but in general when a driver that runs on multiple architectures
> > (including IA64 btw) needs something architecture specific we usually
> > add it to asm, not add ifdefs.
>
> I still wonder why you are so focused on ifdefs. Why would we need those?
Because the Xen drivers will run on a couple of architectures, including
IA64 and PPC.
If IA64 or PPC didn't implement at least wrappers for the sync ops
then they would all need special ifdefs to handle this.
>
> > > What possible use could there be to someone else?
> >
> > e.g. for other hypervisors or possibly for special hardware access
> > (e.g. I could imagine it being used for some kind of cluster interconnect)
> > I remember Alan was using a similar hack in his EDAC drivers because
> > it was the only way to clear ECC errors.
>
> Maybe the best thing would be to have proper atomic ops in UP mode on
> i386? The current way of just dropping the lock bit is the source of the
> troubles.
It's a huge performance difference.
> > Just adding a single line #include for a wrapper asm-generic surely isn't
> > a undue burden for the other architectures, and it will save some
> > mess in the Xen drivers.
>
> Just adding a single line #include <asm/xen-bitops.h> to drivers that need
> this functionality is not an undue burden for the drivers that support
> Xen. They have to use special _xxx bitops anyways.
Ok it could be put into a separate file (although with a neutral name)
But you would still need to add that to IA64, PPC etc. too, so it
would only avoid adding a single to the other architectures.
-Andi
next prev parent reply other threads:[~2006-08-03 5:39 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-03 0:25 [patch 0/8] Basic infrastructure patches for a paravirtualized kernel Jeremy Fitzhardinge
2006-08-03 0:25 ` [patch 1/8] Remove locally-defined ldt structure in favour of standard type Jeremy Fitzhardinge
2006-08-03 0:25 ` [patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor Jeremy Fitzhardinge
2006-08-03 0:28 ` Christoph Lameter
2006-08-03 0:35 ` Jeremy Fitzhardinge
2006-08-03 1:06 ` Christoph Lameter
2006-08-03 1:18 ` Zachary Amsden
2006-08-03 1:25 ` Christoph Lameter
2006-08-03 3:55 ` Andi Kleen
2006-08-03 4:25 ` Christoph Lameter
2006-08-03 4:47 ` Andi Kleen
2006-08-03 2:45 ` Andi Kleen
2006-08-03 4:27 ` Christoph Lameter
2006-08-03 4:49 ` Andi Kleen
2006-08-03 5:19 ` Christoph Lameter
2006-08-03 5:25 ` Andi Kleen
2006-08-03 5:32 ` Christoph Lameter
2006-08-03 5:39 ` Andi Kleen [this message]
2006-08-03 5:54 ` Christoph Lameter
2006-08-03 6:02 ` Andi Kleen
2006-08-03 16:49 ` Christoph Lameter
2006-08-03 17:18 ` Chris Wright
2006-08-04 0:47 ` Andi Kleen
2006-08-04 2:16 ` Christoph Lameter
2006-08-03 0:25 ` [patch 3/8] Allow a kernel to not be in ring 0 Jeremy Fitzhardinge
2006-08-03 0:25 ` [patch 4/8] Replace sensitive instructions with macros Jeremy Fitzhardinge
2006-08-03 0:25 ` [patch 5/8] Roll all the cpuid asm into one __cpuid call Jeremy Fitzhardinge
2006-08-03 0:25 ` [patch 6/8] Make __FIXADDR_TOP variable to allow it to make space for a hypervisor Jeremy Fitzhardinge
2006-08-03 0:25 ` [patch 7/8] Add a bootparameter to reserve high linear address space Jeremy Fitzhardinge
1970-01-01 0:15 ` Pavel Machek
2006-08-07 2:10 ` Andi Kleen
2010-05-04 23:37 ` Jeremy Fitzhardinge
2006-08-03 6:19 ` Andrew Morton
2006-08-03 7:33 ` Zachary Amsden
2006-08-03 7:41 ` Andrew Morton
2006-08-03 8:58 ` Zachary Amsden
2006-08-05 21:58 ` Andrew Morton
2006-08-05 22:52 ` Zachary Amsden
2006-08-05 23:17 ` Rusty Russell
2006-08-03 0:25 ` [patch 8/8] Put .note.* sections into a PT_NOTE segment in vmlinux Jeremy Fitzhardinge
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=200608030739.13334.ak@suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--cc=chrisw@sous-sol.org \
--cc=clameter@sgi.com \
--cc=ian.pratt@xensource.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=virtualization@lists.osdl.org \
--cc=xen-devel@lists.xensource.com \
/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