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
WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <ak@suse.de>
To: Christoph Lameter <clameter@sgi.com>
Cc: akpm@osdl.org, Jeremy Fitzhardinge <jeremy@goop.org>,
xen-devel@lists.xensource.com,
Ian Pratt <ian.pratt@xensource.com>,
linux-kernel@vger.kernel.org, Chris Wright <chrisw@sous-sol.org>,
virtualization@lists.osdl.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: 60+ 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 ` 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:25 ` 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:18 ` Zachary Amsden
2006-08-03 1:25 ` Christoph Lameter
2006-08-03 3:55 ` Andi Kleen
2006-08-03 3:55 ` Andi Kleen
2006-08-03 4:25 ` Christoph Lameter
2006-08-03 4:47 ` Andi Kleen
2006-08-03 4:47 ` Andi Kleen
2006-08-03 2:45 ` 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:25 ` Andi Kleen
2006-08-03 5:32 ` Christoph Lameter
2006-08-03 5:39 ` Andi Kleen [this message]
2006-08-03 5:39 ` Andi Kleen
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-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 ` 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
2006-08-07 2:10 ` Andi Kleen
2010-05-04 23:37 ` Jeremy Fitzhardinge
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:33 ` Zachary Amsden
2006-08-03 7:41 ` Andrew Morton
2006-08-03 8:58 ` Zachary Amsden
2006-08-03 8:58 ` Zachary Amsden
2006-08-05 21:58 ` Andrew Morton
2006-08-05 21:58 ` Andrew Morton
2006-08-05 22:52 ` Zachary Amsden
2006-08-05 22:52 ` Zachary Amsden
2006-08-05 23:17 ` Rusty Russell
2006-08-05 23:17 ` Rusty Russell
2006-08-06 22:00 ` Pavel Machek
2006-08-06 22:02 ` Pavel Machek
2006-08-07 9:12 ` Pavel Machek
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 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.