On 01/21/2014 10:41 AM, Peter Zijlstra wrote:
On Tue, Jan 21, 2014 at 10:02:06AM -0500, Waiman Long wrote:
My latest v9 series of qrwlock patch will automatically adapt to the lack of
atomic byte access by using an atomic integer instruction instead. So the
new series should work for pre-EV56
On Tue, Jan 21, 2014 at 10:02:06AM -0500, Waiman Long wrote:
> My latest v9 series of qrwlock patch will automatically adapt to the lack of
> atomic byte access by using an atomic integer instruction instead. So the
> new series should work for pre-EV56 Alpha, it is just a bit less efficient
> in
On 01/19/2014 03:04 AM, Paul E. McKenney wrote:
On Sat, Jan 18, 2014 at 04:57:05PM -0800, Linus Torvalds wrote:
On Sat, Jan 18, 2014 at 1:22 PM, Paul E. McKenney
wrote:
Yes, this requires that -all- updates to the fields in the machine word
in question use atomic rmw. Which would not be
On 01/19/2014 03:04 AM, Paul E. McKenney wrote:
On Sat, Jan 18, 2014 at 04:57:05PM -0800, Linus Torvalds wrote:
On Sat, Jan 18, 2014 at 1:22 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
Yes, this requires that -all- updates to the fields in the machine word
in question use atomic
On Tue, Jan 21, 2014 at 10:02:06AM -0500, Waiman Long wrote:
My latest v9 series of qrwlock patch will automatically adapt to the lack of
atomic byte access by using an atomic integer instruction instead. So the
new series should work for pre-EV56 Alpha, it is just a bit less efficient
in this
On 01/21/2014 10:41 AM, Peter Zijlstra wrote:
On Tue, Jan 21, 2014 at 10:02:06AM -0500, Waiman Long wrote:
My latest v9 series of qrwlock patch will automatically adapt to the lack of
atomic byte access by using an atomic integer instruction instead. So the
new series should work for pre-EV56
On Sun, Jan 19, 2014 at 11:56:02AM -0800, Linus Torvalds wrote:
> On Sun, Jan 19, 2014 at 12:04 AM, Paul E. McKenney
> wrote:
> >
> > OK, another approach would be to never add "select ARCH_USE_QUEUE_RWLOCK"
> > on Alpha, at least if the queued rwlocks really do want to atomically
> > manipulate
On Sun, Jan 19, 2014 at 12:04 AM, Paul E. McKenney
wrote:
>
> OK, another approach would be to never add "select ARCH_USE_QUEUE_RWLOCK"
> on Alpha, at least if the queued rwlocks really do want to atomically
> manipulate bytes. After all, the Alpha systems that I know about don't
> have enough
On Sat, Jan 18, 2014 at 04:57:05PM -0800, Linus Torvalds wrote:
> On Sat, Jan 18, 2014 at 1:22 PM, Paul E. McKenney
> wrote:
> >
> > Yes, this requires that -all- updates to the fields in the machine word
> > in question use atomic rmw. Which would not be pretty from a core-code
> > perspective.
On Sat, Jan 18, 2014 at 04:57:05PM -0800, Linus Torvalds wrote:
On Sat, Jan 18, 2014 at 1:22 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
Yes, this requires that -all- updates to the fields in the machine word
in question use atomic rmw. Which would not be pretty from a
On Sun, Jan 19, 2014 at 12:04 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
OK, another approach would be to never add select ARCH_USE_QUEUE_RWLOCK
on Alpha, at least if the queued rwlocks really do want to atomically
manipulate bytes. After all, the Alpha systems that I know about
On Sun, Jan 19, 2014 at 11:56:02AM -0800, Linus Torvalds wrote:
On Sun, Jan 19, 2014 at 12:04 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
OK, another approach would be to never add select ARCH_USE_QUEUE_RWLOCK
on Alpha, at least if the queued rwlocks really do want to atomically
On Sat, Jan 18, 2014 at 1:22 PM, Paul E. McKenney
wrote:
>
> Yes, this requires that -all- updates to the fields in the machine word
> in question use atomic rmw. Which would not be pretty from a core-code
> perspective. Hence my suggestion of ceasing Linux-kernel support for
> DEC Alpha CPUs
On Sat, Jan 18, 2014 at 01:41:36PM +0100, Peter Zijlstra wrote:
> On Sat, Jan 18, 2014 at 04:25:48AM -0800, Paul E. McKenney wrote:
> > On Sat, Jan 18, 2014 at 12:34:06PM +0100, Peter Zijlstra wrote:
> > > On Sat, Jan 18, 2014 at 02:01:05AM -0800, Paul E. McKenney wrote:
> > > > OK, I will bite...
On Sat, Jan 18, 2014 at 04:25:48AM -0800, Paul E. McKenney wrote:
> On Sat, Jan 18, 2014 at 12:34:06PM +0100, Peter Zijlstra wrote:
> > On Sat, Jan 18, 2014 at 02:01:05AM -0800, Paul E. McKenney wrote:
> > > OK, I will bite... Aside from fine-grained code timing, what code could
> > > you write
On Sat, Jan 18, 2014 at 12:34:06PM +0100, Peter Zijlstra wrote:
> On Sat, Jan 18, 2014 at 02:01:05AM -0800, Paul E. McKenney wrote:
> > OK, I will bite... Aside from fine-grained code timing, what code could
> > you write to tell the difference between a real one-byte store and an
> > RMW
On Sat, Jan 18, 2014 at 02:01:05AM -0800, Paul E. McKenney wrote:
> OK, I will bite... Aside from fine-grained code timing, what code could
> you write to tell the difference between a real one-byte store and an
> RMW emulating that store?
Why isn't fine-grained code timing an issue? I'm sure
On Thu, Jan 16, 2014 at 11:36:59AM +0100, Peter Zijlstra wrote:
> On Thu, Jan 16, 2014 at 06:39:23AM +0700, Linus Torvalds wrote:
> > On Jan 16, 2014 6:22 AM, "Peter Zijlstra" wrote:
> > >
> > > So while the primitive is called smp_store_release() the !SMP variant
> > > still does:
> > >
> > >
On Thu, Jan 16, 2014 at 11:36:59AM +0100, Peter Zijlstra wrote:
On Thu, Jan 16, 2014 at 06:39:23AM +0700, Linus Torvalds wrote:
On Jan 16, 2014 6:22 AM, Peter Zijlstra pet...@infradead.org wrote:
So while the primitive is called smp_store_release() the !SMP variant
still does:
On Sat, Jan 18, 2014 at 02:01:05AM -0800, Paul E. McKenney wrote:
OK, I will bite... Aside from fine-grained code timing, what code could
you write to tell the difference between a real one-byte store and an
RMW emulating that store?
Why isn't fine-grained code timing an issue? I'm sure Alpha
On Sat, Jan 18, 2014 at 12:34:06PM +0100, Peter Zijlstra wrote:
On Sat, Jan 18, 2014 at 02:01:05AM -0800, Paul E. McKenney wrote:
OK, I will bite... Aside from fine-grained code timing, what code could
you write to tell the difference between a real one-byte store and an
RMW emulating that
On Sat, Jan 18, 2014 at 04:25:48AM -0800, Paul E. McKenney wrote:
On Sat, Jan 18, 2014 at 12:34:06PM +0100, Peter Zijlstra wrote:
On Sat, Jan 18, 2014 at 02:01:05AM -0800, Paul E. McKenney wrote:
OK, I will bite... Aside from fine-grained code timing, what code could
you write to tell
On Sat, Jan 18, 2014 at 01:41:36PM +0100, Peter Zijlstra wrote:
On Sat, Jan 18, 2014 at 04:25:48AM -0800, Paul E. McKenney wrote:
On Sat, Jan 18, 2014 at 12:34:06PM +0100, Peter Zijlstra wrote:
On Sat, Jan 18, 2014 at 02:01:05AM -0800, Paul E. McKenney wrote:
OK, I will bite... Aside
On Sat, Jan 18, 2014 at 1:22 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
Yes, this requires that -all- updates to the fields in the machine word
in question use atomic rmw. Which would not be pretty from a core-code
perspective. Hence my suggestion of ceasing Linux-kernel support
On Thu, Jan 16, 2014 at 06:39:23AM +0700, Linus Torvalds wrote:
> On Jan 16, 2014 6:22 AM, "Peter Zijlstra" wrote:
> >
> > So while the primitive is called smp_store_release() the !SMP variant
> > still does:
> >
> > *(volatile __type *) = ptr;
> >
> > which should not compile on any Alpha pre
On Thu, Jan 16, 2014 at 06:39:23AM +0700, Linus Torvalds wrote:
On Jan 16, 2014 6:22 AM, Peter Zijlstra pet...@infradead.org wrote:
So while the primitive is called smp_store_release() the !SMP variant
still does:
*(volatile __type *) = ptr;
which should not compile on any Alpha
On Wed, Jan 15, 2014 at 12:53:46PM -0800, Paul E. McKenney wrote:
> But we did drop support for SMP i386 quite some time ago, so perhaps
> it is time to drop support for SMP Alpha pre-EV56.
So while the primitive is called smp_store_release() the !SMP variant
still does:
*(volatile __type *)
On Wed, Jan 15, 2014 at 09:07:53AM +0100, Peter Zijlstra wrote:
> On Tue, Jan 14, 2014 at 06:39:58PM -0800, Paul E. McKenney wrote:
> > > If you just want to do a store release, on alpha you'd want to
> > > implement that as a full memory barrier followed by a store. It
> > > doesn't get the
On Tue, Jan 14, 2014 at 06:39:58PM -0800, Paul E. McKenney wrote:
> > If you just want to do a store release, on alpha you'd want to
> > implement that as a full memory barrier followed by a store. It
> > doesn't get the advantage of a real release consistency model, but at
> > least it's not
On Tue, Jan 14, 2014 at 06:39:58PM -0800, Paul E. McKenney wrote:
If you just want to do a store release, on alpha you'd want to
implement that as a full memory barrier followed by a store. It
doesn't get the advantage of a real release consistency model, but at
least it's not doing an
On Wed, Jan 15, 2014 at 09:07:53AM +0100, Peter Zijlstra wrote:
On Tue, Jan 14, 2014 at 06:39:58PM -0800, Paul E. McKenney wrote:
If you just want to do a store release, on alpha you'd want to
implement that as a full memory barrier followed by a store. It
doesn't get the advantage of a
On Wed, Jan 15, 2014 at 12:53:46PM -0800, Paul E. McKenney wrote:
But we did drop support for SMP i386 quite some time ago, so perhaps
it is time to drop support for SMP Alpha pre-EV56.
So while the primitive is called smp_store_release() the !SMP variant
still does:
*(volatile __type *) =
On 01/15/2014 07:44 AM, Paul E. McKenney wrote:
On Tue, Jan 14, 2014 at 10:01:04AM -0800, Richard Henderson wrote:
On 01/14/2014 09:08 AM, Matt Turner wrote:
On Tue, Jan 14, 2014 at 3:03 AM, Peter Zijlstra wrote:
On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote:
Peter,
I
On Wed, Jan 15, 2014 at 07:25:04AM +0700, Linus Torvalds wrote:
> On Wed, Jan 15, 2014 at 6:44 AM, Paul E. McKenney
> wrote:
> >
> > Which means that Alpha should be able to similarly emulate 1-byte and
> > 2-byte atomics, correct?
>
> Not reasonably, no.
>
> The ldl/stc implementation on early
On Wed, Jan 15, 2014 at 6:44 AM, Paul E. McKenney
wrote:
>
> Which means that Alpha should be able to similarly emulate 1-byte and
> 2-byte atomics, correct?
Not reasonably, no.
The ldl/stc implementation on early alpha was so broken as to be
unusable. It's not actually done in the cache, it
On Tue, Jan 14, 2014 at 10:01:04AM -0800, Richard Henderson wrote:
> On 01/14/2014 09:08 AM, Matt Turner wrote:
> > On Tue, Jan 14, 2014 at 3:03 AM, Peter Zijlstra
> > wrote:
> >> On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote:
> Peter,
>
> I found out that the
On Tue, Jan 14, 2014 at 02:09:30PM -0500, Waiman Long wrote:
> I would like to know if the action of writing out a byte (e.g. *byte = 0) is
> atomic in those architectures or is emulated by a compiler-generated
> software read-modify-write.
So on Alpha pre ev56 something like:
*(volatile u8
On 01/14/2014 01:01 PM, Richard Henderson wrote:
On 01/14/2014 09:08 AM, Matt Turner wrote:
On Tue, Jan 14, 2014 at 3:03 AM, Peter Zijlstra wrote:
On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote:
Peter,
I found out that the build failure was caused by the fact that the
On 01/14/2014 09:08 AM, Matt Turner wrote:
> On Tue, Jan 14, 2014 at 3:03 AM, Peter Zijlstra wrote:
>> On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote:
Peter,
I found out that the build failure was caused by the fact that the
__native_word() macro (used
On Tue, Jan 14, 2014 at 3:03 AM, Peter Zijlstra wrote:
> On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote:
>> >Peter,
>> >
>> >I found out that the build failure was caused by the fact that the
>> >__native_word() macro (used internally by compiletime_assert_atomic())
>> >allows
On 01/14/2014 06:03 AM, Peter Zijlstra wrote:
On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote:
Peter,
I found out that the build failure was caused by the fact that the
__native_word() macro (used internally by compiletime_assert_atomic())
allows only a size of 4 or 8 for
On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote:
> >Peter,
> >
> >I found out that the build failure was caused by the fact that the
> >__native_word() macro (used internally by compiletime_assert_atomic())
> >allows only a size of 4 or 8 for x86-64. The data type that I used is a
On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote:
Peter,
I found out that the build failure was caused by the fact that the
__native_word() macro (used internally by compiletime_assert_atomic())
allows only a size of 4 or 8 for x86-64. The data type that I used is a
byte. Is
On 01/14/2014 06:03 AM, Peter Zijlstra wrote:
On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote:
Peter,
I found out that the build failure was caused by the fact that the
__native_word() macro (used internally by compiletime_assert_atomic())
allows only a size of 4 or 8 for
On Tue, Jan 14, 2014 at 3:03 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote:
Peter,
I found out that the build failure was caused by the fact that the
__native_word() macro (used internally by compiletime_assert_atomic())
On 01/14/2014 09:08 AM, Matt Turner wrote:
On Tue, Jan 14, 2014 at 3:03 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote:
Peter,
I found out that the build failure was caused by the fact that the
__native_word() macro (used
On 01/14/2014 01:01 PM, Richard Henderson wrote:
On 01/14/2014 09:08 AM, Matt Turner wrote:
On Tue, Jan 14, 2014 at 3:03 AM, Peter Zijlstrapet...@infradead.org wrote:
On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote:
Peter,
I found out that the build failure was caused by
On Tue, Jan 14, 2014 at 02:09:30PM -0500, Waiman Long wrote:
I would like to know if the action of writing out a byte (e.g. *byte = 0) is
atomic in those architectures or is emulated by a compiler-generated
software read-modify-write.
So on Alpha pre ev56 something like:
*(volatile u8 *)foo
On Tue, Jan 14, 2014 at 10:01:04AM -0800, Richard Henderson wrote:
On 01/14/2014 09:08 AM, Matt Turner wrote:
On Tue, Jan 14, 2014 at 3:03 AM, Peter Zijlstra pet...@infradead.org
wrote:
On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman wrote:
Peter,
I found out that the
On Wed, Jan 15, 2014 at 6:44 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
Which means that Alpha should be able to similarly emulate 1-byte and
2-byte atomics, correct?
Not reasonably, no.
The ldl/stc implementation on early alpha was so broken as to be
unusable. It's not actually
On Wed, Jan 15, 2014 at 07:25:04AM +0700, Linus Torvalds wrote:
On Wed, Jan 15, 2014 at 6:44 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
Which means that Alpha should be able to similarly emulate 1-byte and
2-byte atomics, correct?
Not reasonably, no.
The ldl/stc
On 01/15/2014 07:44 AM, Paul E. McKenney wrote:
On Tue, Jan 14, 2014 at 10:01:04AM -0800, Richard Henderson wrote:
On 01/14/2014 09:08 AM, Matt Turner wrote:
On Tue, Jan 14, 2014 at 3:03 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, Jan 14, 2014 at 10:28:23AM +0800, Daniel J Blueman
On 14/01/2014 00:41, Waiman Long wrote:
On 01/12/2014 09:47 PM, Daniel J Blueman wrote:
On Thursday, 9 January 2014 01:10:03 UTC+8, Waiman Long wrote:
> This patch modifies the queue_write_unlock() function to use the
> new smp_store_release() function in another pending patch. It also
>
On 01/12/2014 09:47 PM, Daniel J Blueman wrote:
On Thursday, 9 January 2014 01:10:03 UTC+8, Waiman Long wrote:
> This patch modifies the queue_write_unlock() function to use the
> new smp_store_release() function in another pending patch. It also
> removes the temporary implementation of
On 01/12/2014 09:47 PM, Daniel J Blueman wrote:
On Thursday, 9 January 2014 01:10:03 UTC+8, Waiman Long wrote:
This patch modifies the queue_write_unlock() function to use the
new smp_store_release() function in another pending patch. It also
removes the temporary implementation of
On 14/01/2014 00:41, Waiman Long wrote:
On 01/12/2014 09:47 PM, Daniel J Blueman wrote:
On Thursday, 9 January 2014 01:10:03 UTC+8, Waiman Long wrote:
This patch modifies the queue_write_unlock() function to use the
new smp_store_release() function in another pending patch. It also
removes
On Mon, Jan 13, 2014 at 10:47:36AM +0800, Daniel J Blueman wrote:
> On Thursday, 9 January 2014 01:10:03 UTC+8, Waiman Long wrote:
> > This patch modifies the queue_write_unlock() function to use the
> > new smp_store_release() function in another pending patch. It also
> > removes the temporary
On Thursday, 9 January 2014 01:10:03 UTC+8, Waiman Long wrote:
> This patch modifies the queue_write_unlock() function to use the
> new smp_store_release() function in another pending patch. It also
> removes the temporary implementation of smp_load_acquire() and
> smp_store_release() function
On Thursday, 9 January 2014 01:10:03 UTC+8, Waiman Long wrote:
This patch modifies the queue_write_unlock() function to use the
new smp_store_release() function in another pending patch. It also
removes the temporary implementation of smp_load_acquire() and
smp_store_release() function in
On Mon, Jan 13, 2014 at 10:47:36AM +0800, Daniel J Blueman wrote:
On Thursday, 9 January 2014 01:10:03 UTC+8, Waiman Long wrote:
This patch modifies the queue_write_unlock() function to use the
new smp_store_release() function in another pending patch. It also
removes the temporary
60 matches
Mail list logo
