H. Peter Anvin wrote:
> Any news on this? Can we perhaps help making this go forward at some point?
I'm just bringing my patches up to date with an eye on extracting and pushing
the more general (ie. less contentious) bits.
David
On 06/22/16 09:14, David Howells wrote:
> H. Peter Anvin wrote:
>
>> So how do we make this move forward?
>
> Getting my API additions in is relatively straightforward, I think. The
> whether-or-notness of the cmpxchg operation succeeding can be calculated by
> comparing the original value read
On 06/22/16 10:11, Linus Torvalds wrote:
>
> I thought Richard Henderson already had a patch for the condition code
> asm outputs, but maybe I misremember.
>
It is already in the released version of gcc 6.1; there is a patchset in
-tip already for using it for everything other than cmpxchg using
On Wed, Jun 22, 2016 at 9:36 AM, H. Peter Anvin wrote:
>
> I am kind of hesitant to put knowledge of this into gcc, because it
> freezes something that currently is not gcc-dependent (although we could
> separate out the gcc-generated and non-gcc-generated bits if we really
> care.)
I'm pretty do
On 06/22/16 09:11, David Howells wrote:
> H. Peter Anvin wrote:
>
>> The question for me is for things like lock patching that we do on x86...
>
> This might be pertinent to what you're asking:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70973
>
I am kind of hesitant to put knowled
H. Peter Anvin wrote:
> So how do we make this move forward?
Getting my API additions in is relatively straightforward, I think. The
whether-or-notness of the cmpxchg operation succeeding can be calculated by
comparing the original value read from memory with the value-to-be-replaced
inside the
H. Peter Anvin wrote:
> The question for me is for things like lock patching that we do on x86...
This might be pertinent to what you're asking:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70973
David
On 06/21/16 10:24, H. Peter Anvin wrote:
> On 06/21/16 02:06, David Howells wrote:
>>
>> However, there's probably not a great deal of difference to be had if the
>> inline asm codes the appropriate instruction in each case for something like
>> x86*. The emitted code ought to look the same. The
On 06/21/16 02:06, David Howells wrote:
>
> However, there's probably not a great deal of difference to be had if the
> inline asm codes the appropriate instruction in each case for something like
> x86*. The emitted code ought to look the same. The second biggest win for
> the intriniscs, I thi
On June 21, 2016 2:06:20 AM PDT, David Howells wrote:
>H. Peter Anvin wrote:
>
>> Well, that sounds promising. I wonder how David's model, using
>> intrinsics (do we have enough intrinsics to actually be able to do
>this
>> "correctly"?), compare to using the flags output from assembly.
>
>There
H. Peter Anvin wrote:
> Well, that sounds promising. I wonder how David's model, using
> intrinsics (do we have enough intrinsics to actually be able to do this
> "correctly"?), compare to using the flags output from assembly.
There is an advantage to using the intriniscs on arches with explici
On 06/15/16 01:50, Peter Zijlstra wrote:
>>
>> It seems to me that the sanest way to handle this is to add a new
>> interface with a fourth parameter, so:
>>
>> changed = cmpxchgx(ptr, old, new, out);
>
> See also:
>
>
> lkml.kernel.org/r/146358429016.8596.3381723959064491676.st...@wartho
On Tue, Jun 14, 2016 at 04:53:00PM -0700, H. Peter Anvin wrote:
> The x86 gcc now has the ability to return the value of flags output. In
> most use cases, this has been trivial to use in the kernel.
>
> However, cmpxchg() presents a problem. The current definition of
> cmpxchg() and its variant
Dave Airlie wrote:
On 7/19/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Thu, 19 Jul 2007 18:15:03 +1000 "Dave Airlie" <[EMAIL PROTECTED]>
wrote:
> Maybe we could add CONFIG_HAVE_CMPXCHG and let DRM depend on it..
That would certainly be better than adding a sprinkle of architectures
in DR
From: "Dave Airlie" <[EMAIL PROTECTED]>
Date: Thu, 19 Jul 2007 18:15:03 +1000
> Maybe we could add CONFIG_HAVE_CMPXCHG and let DRM depend on it..
There is already a "!EMULATED_CMPXCHG" guarding DRM, perhaps
ARM's Kconfig can set that if appropriate.
-
To unsubscribe from this list: send the line
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Thu, 19 Jul 2007 01:21:41 -0700
> On Thu, 19 Jul 2007 18:15:03 +1000 "Dave Airlie" <[EMAIL PROTECTED]> wrote:
>
> > Maybe we could add CONFIG_HAVE_CMPXCHG and let DRM depend on it..
>
> That would certainly be better than adding a sprinkle of archite
they need to grow a userpsace
cmpxchg as davem mentioned to go along with this, changing the drm now
isn't possible due to backwards compat..
For reference purposes, that position is not acceptable. We _never_ accept the
"oh I can't change my proposed kernel interface because I already have
On 7/19/07, David Miller <[EMAIL PROTECTED]> wrote:
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Thu, 19 Jul 2007 00:05:49 -0700
> What's that code doing anyway? driver-private locking primitives?
It's an atomic lock shared with userspace. Whatever implementation is
used to do the lock on th
arm:
drivers/char/drm/drm_lock.c: In function `drm_lock_take':
drivers/char/drm/drm_lock.c:221: error: implicit declaration of function
`cmpxchg'
You might be able to use atomic_cmpxchg, which _is_ present
on all architectures. Or use a spinlock.
What's that code doing anyway? driver-priv
On Thu, 19 Jul 2007 09:19:10 +0100 (IST) Dave Airlie <[EMAIL PROTECTED]> wrote:
> >
> >> they need to grow a userpsace
> >> cmpxchg as davem mentioned to go along with this, changing the drm now
> >> isn't possible due to backwards compat..
> >
> > For reference purposes, that position is not acce
On Thu, 19 Jul 2007 18:15:03 +1000 "Dave Airlie" <[EMAIL PROTECTED]> wrote:
> Maybe we could add CONFIG_HAVE_CMPXCHG and let DRM depend on it..
That would certainly be better than adding a sprinkle of architectures
in DRM Kconfig dependencies.
I don't know how important DRM is on ARM. Zero?
-
T
On Thu, 19 Jul 2007 09:02:03 +0100 (IST) Dave Airlie <[EMAIL PROTECTED]> wrote:
>
>
> > arm:
> >
> > drivers/char/drm/drm_lock.c: In function `drm_lock_take':
> > drivers/char/drm/drm_lock.c:221: error: implicit declaration of function
> > `cmpxchg'
> >
> > You might be able to use atomic_cmpxc
On 7/19/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Thu, 19 Jul 2007 18:15:03 +1000 "Dave Airlie" <[EMAIL PROTECTED]> wrote:
> Maybe we could add CONFIG_HAVE_CMPXCHG and let DRM depend on it..
That would certainly be better than adding a sprinkle of architectures
in DRM Kconfig dependencies
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Thu, 19 Jul 2007 00:05:49 -0700
> What's that code doing anyway? driver-private locking primitives?
It's an atomic lock shared with userspace. Whatever implementation is
used to do the lock on that object must be identical in the userspace
DRM bits.
On Thu, 07 Dec 2006 11:46:24 +
David Howells <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > I don't see why the 2.6.19 logic needed changing.
> >
> > a) Nobody should be freeing the work_struct itself without running
> >flush_scheduled_work() and
> >
> > b)
On Thu, Dec 07, 2006 at 12:09:50AM -0800, David Miller wrote:
> Also, because Alan Cox's machine (zeniv) went down, a few folks such
> as Al Viro (CC:'d) had no opportunity to comment on your changes
> before they went in.
Special thanks should be given to Vince Sanders and Leslie Mitchell for
sou
[adding linux-arch to the CC list]
David Miller <[EMAIL PROTECTED]> wrote:
> David, you have to fix the locking scheme used in kernel/workqueue.c,
> you absolutely cannot assume that cmpxchg() is available on all
> platforms. This breaks the build on the platforms that don't
> have such an inst
Andrew Morton <[EMAIL PROTECTED]> wrote:
> I don't see why the 2.6.19 logic needed changing.
>
> a) Nobody should be freeing the work_struct itself without running
>flush_scheduled_work() and
>
> b) even if the work_struct _did_ get freed, the callback function won't
>care, because there
On Thu, 07 Dec 2006 11:03:49 +
David Howells <[EMAIL PROTECTED]> wrote:
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > David, you have to fix the locking scheme used in kernel/workqueue.c,
> > you absolutely cannot assume that cmpxchg() is available on all
> > platforms. This breaks the bui
David Miller <[EMAIL PROTECTED]> wrote:
> David, you have to fix the locking scheme used in kernel/workqueue.c,
> you absolutely cannot assume that cmpxchg() is available on all
> platforms. This breaks the build on the platforms that don't
> have such an instruction, and no it cannot emulated.
On Thu, Dec 07, 2006 at 12:09:50AM -0800, David Miller wrote:
>
> David, you have to fix the locking scheme used in kernel/workqueue.c,
> you absolutely cannot assume that cmpxchg() is available on all
> platforms. This breaks the build on the platforms that don't
> have such an instruction, and
On Wed, May 16, 2001 at 03:37:00PM -0700, Scott Huang wrote:
> Four adapters need to produce data to a
> descriptor queue which is consumed by a
> user process. A lock mechanism was implemented
> to sync the adapters. However, this causes
> a performance hit. Is it possible to use
> CMPXCHG on
32 matches
Mail list logo
