On Mon, 9 Jul 2018, Daniel Lustig wrote:
> On 7/9/2018 9:52 AM, Will Deacon wrote:
> > On Fri, Jul 06, 2018 at 02:10:55PM -0700, Paul E. McKenney wrote:
> >> On Fri, Jul 06, 2018 at 04:37:21PM -0400, Alan Stern wrote:
> >>> On Thu, 5 Jul 2018, Andrea Parri wrote:
> >>>
> > At any rate, it
On Mon, 9 Jul 2018, Daniel Lustig wrote:
> On 7/9/2018 9:52 AM, Will Deacon wrote:
> > On Fri, Jul 06, 2018 at 02:10:55PM -0700, Paul E. McKenney wrote:
> >> On Fri, Jul 06, 2018 at 04:37:21PM -0400, Alan Stern wrote:
> >>> On Thu, 5 Jul 2018, Andrea Parri wrote:
> >>>
> > At any rate, it
On 7/9/2018 9:52 AM, Will Deacon wrote:
> On Fri, Jul 06, 2018 at 02:10:55PM -0700, Paul E. McKenney wrote:
>> On Fri, Jul 06, 2018 at 04:37:21PM -0400, Alan Stern wrote:
>>> On Thu, 5 Jul 2018, Andrea Parri wrote:
>>>
> At any rate, it looks like instead of strengthening the relation, I
>
On 7/9/2018 9:52 AM, Will Deacon wrote:
> On Fri, Jul 06, 2018 at 02:10:55PM -0700, Paul E. McKenney wrote:
>> On Fri, Jul 06, 2018 at 04:37:21PM -0400, Alan Stern wrote:
>>> On Thu, 5 Jul 2018, Andrea Parri wrote:
>>>
> At any rate, it looks like instead of strengthening the relation, I
>
On Fri, Jul 06, 2018 at 02:10:55PM -0700, Paul E. McKenney wrote:
> On Fri, Jul 06, 2018 at 04:37:21PM -0400, Alan Stern wrote:
> > On Thu, 5 Jul 2018, Andrea Parri wrote:
> >
> > > > At any rate, it looks like instead of strengthening the relation, I
> > > > should write a patch that removes it
On Fri, Jul 06, 2018 at 02:10:55PM -0700, Paul E. McKenney wrote:
> On Fri, Jul 06, 2018 at 04:37:21PM -0400, Alan Stern wrote:
> > On Thu, 5 Jul 2018, Andrea Parri wrote:
> >
> > > > At any rate, it looks like instead of strengthening the relation, I
> > > > should write a patch that removes it
On Fri, Jul 06, 2018 at 04:37:21PM -0400, Alan Stern wrote:
> On Thu, 5 Jul 2018, Andrea Parri wrote:
>
> > > At any rate, it looks like instead of strengthening the relation, I
> > > should write a patch that removes it entirely. I also will add new,
> > > stronger relations for use with
On Fri, Jul 06, 2018 at 04:37:21PM -0400, Alan Stern wrote:
> On Thu, 5 Jul 2018, Andrea Parri wrote:
>
> > > At any rate, it looks like instead of strengthening the relation, I
> > > should write a patch that removes it entirely. I also will add new,
> > > stronger relations for use with
On Thu, 5 Jul 2018, Andrea Parri wrote:
> > At any rate, it looks like instead of strengthening the relation, I
> > should write a patch that removes it entirely. I also will add new,
> > stronger relations for use with locking, essentially making spin_lock
> > and spin_unlock be RCsc.
>
>
On Thu, 5 Jul 2018, Andrea Parri wrote:
> > At any rate, it looks like instead of strengthening the relation, I
> > should write a patch that removes it entirely. I also will add new,
> > stronger relations for use with locking, essentially making spin_lock
> > and spin_unlock be RCsc.
>
>
On Fri, Jul 06, 2018 at 10:25:29AM +0100, Will Deacon wrote:
> On Thu, Jul 05, 2018 at 09:56:02AM -0700, Paul E. McKenney wrote:
> > On Thu, Jul 05, 2018 at 05:22:26PM +0100, Will Deacon wrote:
> > > On Thu, Jul 05, 2018 at 08:44:39AM -0700, Daniel Lustig wrote:
> > > > On 7/5/2018 8:31 AM, Paul
On Fri, Jul 06, 2018 at 10:25:29AM +0100, Will Deacon wrote:
> On Thu, Jul 05, 2018 at 09:56:02AM -0700, Paul E. McKenney wrote:
> > On Thu, Jul 05, 2018 at 05:22:26PM +0100, Will Deacon wrote:
> > > On Thu, Jul 05, 2018 at 08:44:39AM -0700, Daniel Lustig wrote:
> > > > On 7/5/2018 8:31 AM, Paul
On Thu, Jul 05, 2018 at 09:56:02AM -0700, Paul E. McKenney wrote:
> On Thu, Jul 05, 2018 at 05:22:26PM +0100, Will Deacon wrote:
> > On Thu, Jul 05, 2018 at 08:44:39AM -0700, Daniel Lustig wrote:
> > > On 7/5/2018 8:31 AM, Paul E. McKenney wrote:
> > > > On Thu, Jul 05, 2018 at 10:21:36AM -0400,
On Thu, Jul 05, 2018 at 09:56:02AM -0700, Paul E. McKenney wrote:
> On Thu, Jul 05, 2018 at 05:22:26PM +0100, Will Deacon wrote:
> > On Thu, Jul 05, 2018 at 08:44:39AM -0700, Daniel Lustig wrote:
> > > On 7/5/2018 8:31 AM, Paul E. McKenney wrote:
> > > > On Thu, Jul 05, 2018 at 10:21:36AM -0400,
On Thu, Jul 05, 2018 at 08:44:10PM +0200, Andrea Parri wrote:
> On Thu, Jul 05, 2018 at 08:38:36PM +0200, Andrea Parri wrote:
> > > No, I'm definitely not pushing for anything stronger. I'm still just
> > > wondering if the name "RCsc" is right for what you described. For
> > > example, Andrea
On Thu, Jul 05, 2018 at 08:44:10PM +0200, Andrea Parri wrote:
> On Thu, Jul 05, 2018 at 08:38:36PM +0200, Andrea Parri wrote:
> > > No, I'm definitely not pushing for anything stronger. I'm still just
> > > wondering if the name "RCsc" is right for what you described. For
> > > example, Andrea
On Thu, Jul 05, 2018 at 08:38:36PM +0200, Andrea Parri wrote:
> > No, I'm definitely not pushing for anything stronger. I'm still just
> > wondering if the name "RCsc" is right for what you described. For
> > example, Andrea just said this in a parallel email:
> >
> > > "RCsc" as ordering
On Thu, Jul 05, 2018 at 08:38:36PM +0200, Andrea Parri wrote:
> > No, I'm definitely not pushing for anything stronger. I'm still just
> > wondering if the name "RCsc" is right for what you described. For
> > example, Andrea just said this in a parallel email:
> >
> > > "RCsc" as ordering
On Thu, Jul 05, 2018 at 08:38:36PM +0200, Andrea Parri wrote:
> > No, I'm definitely not pushing for anything stronger. I'm still just
> > wondering if the name "RCsc" is right for what you described. For
> > example, Andrea just said this in a parallel email:
> >
> > > "RCsc" as ordering
On Thu, Jul 05, 2018 at 08:38:36PM +0200, Andrea Parri wrote:
> > No, I'm definitely not pushing for anything stronger. I'm still just
> > wondering if the name "RCsc" is right for what you described. For
> > example, Andrea just said this in a parallel email:
> >
> > > "RCsc" as ordering
> No, I'm definitely not pushing for anything stronger. I'm still just
> wondering if the name "RCsc" is right for what you described. For
> example, Andrea just said this in a parallel email:
>
> > "RCsc" as ordering everything except for W -> R, without the [extra]
> > barriers
And I already
> No, I'm definitely not pushing for anything stronger. I'm still just
> wondering if the name "RCsc" is right for what you described. For
> example, Andrea just said this in a parallel email:
>
> > "RCsc" as ordering everything except for W -> R, without the [extra]
> > barriers
And I already
On 7/5/2018 9:56 AM, Paul E. McKenney wrote:
> On Thu, Jul 05, 2018 at 05:22:26PM +0100, Will Deacon wrote:
>> On Thu, Jul 05, 2018 at 08:44:39AM -0700, Daniel Lustig wrote:
>>> On 7/5/2018 8:31 AM, Paul E. McKenney wrote:
On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
> At
On 7/5/2018 9:56 AM, Paul E. McKenney wrote:
> On Thu, Jul 05, 2018 at 05:22:26PM +0100, Will Deacon wrote:
>> On Thu, Jul 05, 2018 at 08:44:39AM -0700, Daniel Lustig wrote:
>>> On 7/5/2018 8:31 AM, Paul E. McKenney wrote:
On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
> At
On Thu, Jul 05, 2018 at 09:58:48AM -0700, Paul E. McKenney wrote:
> On Thu, Jul 05, 2018 at 05:39:06PM +0200, Andrea Parri wrote:
> > > > At any rate, it looks like instead of strengthening the relation, I
> > > > should write a patch that removes it entirely. I also will add new,
> > > >
On Thu, Jul 05, 2018 at 09:58:48AM -0700, Paul E. McKenney wrote:
> On Thu, Jul 05, 2018 at 05:39:06PM +0200, Andrea Parri wrote:
> > > > At any rate, it looks like instead of strengthening the relation, I
> > > > should write a patch that removes it entirely. I also will add new,
> > > >
On Thu, Jul 05, 2018 at 05:39:06PM +0200, Andrea Parri wrote:
> > > At any rate, it looks like instead of strengthening the relation, I
> > > should write a patch that removes it entirely. I also will add new,
> > > stronger relations for use with locking, essentially making spin_lock
> > > and
On Thu, Jul 05, 2018 at 05:39:06PM +0200, Andrea Parri wrote:
> > > At any rate, it looks like instead of strengthening the relation, I
> > > should write a patch that removes it entirely. I also will add new,
> > > stronger relations for use with locking, essentially making spin_lock
> > > and
On Thu, Jul 05, 2018 at 05:22:26PM +0100, Will Deacon wrote:
> On Thu, Jul 05, 2018 at 08:44:39AM -0700, Daniel Lustig wrote:
> > On 7/5/2018 8:31 AM, Paul E. McKenney wrote:
> > > On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
> > >> At any rate, it looks like instead of
On Thu, Jul 05, 2018 at 05:22:26PM +0100, Will Deacon wrote:
> On Thu, Jul 05, 2018 at 08:44:39AM -0700, Daniel Lustig wrote:
> > On 7/5/2018 8:31 AM, Paul E. McKenney wrote:
> > > On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
> > >> At any rate, it looks like instead of
On Thu, Jul 05, 2018 at 08:44:39AM -0700, Daniel Lustig wrote:
> On 7/5/2018 8:31 AM, Paul E. McKenney wrote:
> > On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
> >> At any rate, it looks like instead of strengthening the relation, I
> >> should write a patch that removes it entirely.
On Thu, Jul 05, 2018 at 08:44:39AM -0700, Daniel Lustig wrote:
> On 7/5/2018 8:31 AM, Paul E. McKenney wrote:
> > On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
> >> At any rate, it looks like instead of strengthening the relation, I
> >> should write a patch that removes it entirely.
On 7/5/2018 8:31 AM, Paul E. McKenney wrote:
> On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
>> At any rate, it looks like instead of strengthening the relation, I
>> should write a patch that removes it entirely. I also will add new,
>> stronger relations for use with locking,
On 7/5/2018 8:31 AM, Paul E. McKenney wrote:
> On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
>> At any rate, it looks like instead of strengthening the relation, I
>> should write a patch that removes it entirely. I also will add new,
>> stronger relations for use with locking,
> > At any rate, it looks like instead of strengthening the relation, I
> > should write a patch that removes it entirely. I also will add new,
> > stronger relations for use with locking, essentially making spin_lock
> > and spin_unlock be RCsc.
>
> Only in the presence of
> > At any rate, it looks like instead of strengthening the relation, I
> > should write a patch that removes it entirely. I also will add new,
> > stronger relations for use with locking, essentially making spin_lock
> > and spin_unlock be RCsc.
>
> Only in the presence of
On 7/5/2018 8:16 AM, Daniel Lustig wrote:
> On 7/5/2018 7:44 AM, Will Deacon wrote:
>> Andrea,
>>
>> On Thu, Jul 05, 2018 at 04:00:29PM +0200, Andrea Parri wrote:
>>> On Wed, Jul 04, 2018 at 01:11:04PM +0100, Will Deacon wrote:
On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
>
On 7/5/2018 8:16 AM, Daniel Lustig wrote:
> On 7/5/2018 7:44 AM, Will Deacon wrote:
>> Andrea,
>>
>> On Thu, Jul 05, 2018 at 04:00:29PM +0200, Andrea Parri wrote:
>>> On Wed, Jul 04, 2018 at 01:11:04PM +0100, Will Deacon wrote:
On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
>
On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
> On Wed, 4 Jul 2018, Will Deacon wrote:
>
> > Hi Alan,
> >
> > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > > On Mon, 25 Jun 2018, Andrea Parri wrote:
> > >
> > > > On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will
On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
> On Wed, 4 Jul 2018, Will Deacon wrote:
>
> > Hi Alan,
> >
> > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > > On Mon, 25 Jun 2018, Andrea Parri wrote:
> > >
> > > > On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will
On Thu, Jul 05, 2018 at 10:23:01AM -0400, Alan Stern wrote:
> On Wed, 4 Jul 2018, Will Deacon wrote:
>
> > On Wed, Jul 04, 2018 at 04:28:52AM -0700, Paul E. McKenney wrote:
> > > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > > > PS: Paul, is the patch which introduced
On Thu, Jul 05, 2018 at 10:23:01AM -0400, Alan Stern wrote:
> On Wed, 4 Jul 2018, Will Deacon wrote:
>
> > On Wed, Jul 04, 2018 at 04:28:52AM -0700, Paul E. McKenney wrote:
> > > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > > > PS: Paul, is the patch which introduced
On 7/5/2018 7:44 AM, Will Deacon wrote:
> Andrea,
>
> On Thu, Jul 05, 2018 at 04:00:29PM +0200, Andrea Parri wrote:
>> On Wed, Jul 04, 2018 at 01:11:04PM +0100, Will Deacon wrote:
>>> On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
There's also read-write ordering, in the form of
On 7/5/2018 7:44 AM, Will Deacon wrote:
> Andrea,
>
> On Thu, Jul 05, 2018 at 04:00:29PM +0200, Andrea Parri wrote:
>> On Wed, Jul 04, 2018 at 01:11:04PM +0100, Will Deacon wrote:
>>> On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
There's also read-write ordering, in the form of
On Thu, Jul 05, 2018 at 10:57:28AM -0400, Alan Stern wrote:
> On Thu, 5 Jul 2018, Will Deacon wrote:
> > On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
> > > On Wed, 4 Jul 2018, Will Deacon wrote:
> > > > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > > > > Would this
On Thu, Jul 05, 2018 at 10:57:28AM -0400, Alan Stern wrote:
> On Thu, 5 Jul 2018, Will Deacon wrote:
> > On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
> > > On Wed, 4 Jul 2018, Will Deacon wrote:
> > > > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > > > > Would this
> At any rate, it looks like instead of strengthening the relation, I
> should write a patch that removes it entirely. I also will add new,
> stronger relations for use with locking, essentially making spin_lock
> and spin_unlock be RCsc.
Thank you.
Ah let me put this forward: please keep an
> At any rate, it looks like instead of strengthening the relation, I
> should write a patch that removes it entirely. I also will add new,
> stronger relations for use with locking, essentially making spin_lock
> and spin_unlock be RCsc.
Thank you.
Ah let me put this forward: please keep an
Will:
On Thu, 5 Jul 2018, Will Deacon wrote:
> On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
> > On Wed, 4 Jul 2018, Will Deacon wrote:
> > > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > > > Would this be allowed if smp_load_acquire() was implemented with LDAPR?
Will:
On Thu, 5 Jul 2018, Will Deacon wrote:
> On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
> > On Wed, 4 Jul 2018, Will Deacon wrote:
> > > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > > > Would this be allowed if smp_load_acquire() was implemented with LDAPR?
On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
> On Wed, 4 Jul 2018, Will Deacon wrote:
> > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > > Would this be allowed if smp_load_acquire() was implemented with LDAPR?
> > > If the answer is yes then we will have to remove
On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
> On Wed, 4 Jul 2018, Will Deacon wrote:
> > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > > Would this be allowed if smp_load_acquire() was implemented with LDAPR?
> > > If the answer is yes then we will have to remove
Andrea,
On Thu, Jul 05, 2018 at 04:00:29PM +0200, Andrea Parri wrote:
> On Wed, Jul 04, 2018 at 01:11:04PM +0100, Will Deacon wrote:
> > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > > There's also read-write ordering, in the form of the LB pattern:
> > >
> > > P0(int *x, int
Andrea,
On Thu, Jul 05, 2018 at 04:00:29PM +0200, Andrea Parri wrote:
> On Wed, Jul 04, 2018 at 01:11:04PM +0100, Will Deacon wrote:
> > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > > There's also read-write ordering, in the form of the LB pattern:
> > >
> > > P0(int *x, int
On Wed, 4 Jul 2018, Will Deacon wrote:
> On Wed, Jul 04, 2018 at 04:28:52AM -0700, Paul E. McKenney wrote:
> > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > > PS: Paul, is the patch which introduced rel-rf-acq-po currently present
> > > in any of your branches? I couldn't find
On Wed, 4 Jul 2018, Will Deacon wrote:
> On Wed, Jul 04, 2018 at 04:28:52AM -0700, Paul E. McKenney wrote:
> > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > > PS: Paul, is the patch which introduced rel-rf-acq-po currently present
> > > in any of your branches? I couldn't find
On Wed, 4 Jul 2018, Will Deacon wrote:
> Hi Alan,
>
> On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > On Mon, 25 Jun 2018, Andrea Parri wrote:
> >
> > > On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will Deacon wrote:
> > > > > > I think the second example would preclude us using
On Wed, 4 Jul 2018, Will Deacon wrote:
> Hi Alan,
>
> On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > On Mon, 25 Jun 2018, Andrea Parri wrote:
> >
> > > On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will Deacon wrote:
> > > > > > I think the second example would preclude us using
On Wed, Jul 04, 2018 at 01:11:04PM +0100, Will Deacon wrote:
> Hi Alan,
>
> On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > On Mon, 25 Jun 2018, Andrea Parri wrote:
> >
> > > On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will Deacon wrote:
> > > > > > I think the second example would
On Wed, Jul 04, 2018 at 01:11:04PM +0100, Will Deacon wrote:
> Hi Alan,
>
> On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > On Mon, 25 Jun 2018, Andrea Parri wrote:
> >
> > > On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will Deacon wrote:
> > > > > > I think the second example would
On Wed, Jul 04, 2018 at 04:28:52AM -0700, Paul E. McKenney wrote:
> On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > PS: Paul, is the patch which introduced rel-rf-acq-po currently present
> > in any of your branches? I couldn't find it.
>
> It is not, I will add it back in. I
On Wed, Jul 04, 2018 at 04:28:52AM -0700, Paul E. McKenney wrote:
> On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > PS: Paul, is the patch which introduced rel-rf-acq-po currently present
> > in any of your branches? I couldn't find it.
>
> It is not, I will add it back in. I
Hi Alan,
On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> On Mon, 25 Jun 2018, Andrea Parri wrote:
>
> > On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will Deacon wrote:
> > > > > I think the second example would preclude us using LDAPR for
> > > > > load-acquire,
> >
> > > I don't
Hi Alan,
On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> On Mon, 25 Jun 2018, Andrea Parri wrote:
>
> > On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will Deacon wrote:
> > > > > I think the second example would preclude us using LDAPR for
> > > > > load-acquire,
> >
> > > I don't
Hi Alan,
On Fri, Jun 22, 2018 at 03:11:37PM -0400, Alan Stern wrote:
> On Fri, 22 Jun 2018, Will Deacon wrote:
> > On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote:
> > > On Fri, 22 Jun 2018, Will Deacon wrote:
> > > > Could we drop the acquire/release stuff from the patch and limit
Hi Alan,
On Fri, Jun 22, 2018 at 03:11:37PM -0400, Alan Stern wrote:
> On Fri, 22 Jun 2018, Will Deacon wrote:
> > On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote:
> > > On Fri, 22 Jun 2018, Will Deacon wrote:
> > > > Could we drop the acquire/release stuff from the patch and limit
On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> Will:
>
> On Mon, 25 Jun 2018, Andrea Parri wrote:
>
> > On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will Deacon wrote:
> > > > > I think the second example would preclude us using LDAPR for
> > > > > load-acquire,
> >
> > > I don't
On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> Will:
>
> On Mon, 25 Jun 2018, Andrea Parri wrote:
>
> > On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will Deacon wrote:
> > > > > I think the second example would preclude us using LDAPR for
> > > > > load-acquire,
> >
> > > I don't
Will:
On Mon, 25 Jun 2018, Andrea Parri wrote:
> On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will Deacon wrote:
> > > > I think the second example would preclude us using LDAPR for
> > > > load-acquire,
>
> > I don't think it's a moot point. We want new architectures to implement
> >
Will:
On Mon, 25 Jun 2018, Andrea Parri wrote:
> On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will Deacon wrote:
> > > > I think the second example would preclude us using LDAPR for
> > > > load-acquire,
>
> > I don't think it's a moot point. We want new architectures to implement
> >
On Mon, Jun 25, 2018 at 10:29:23AM +0200, Andrea Parri wrote:
> On Mon, Jun 25, 2018 at 09:32:29AM +0200, Peter Zijlstra wrote:
> >
> > I have yet to digest the rest of the discussion, however:
> >
> > On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote:
> > > The LKMM uses the same CAT
On Mon, Jun 25, 2018 at 10:29:23AM +0200, Andrea Parri wrote:
> On Mon, Jun 25, 2018 at 09:32:29AM +0200, Peter Zijlstra wrote:
> >
> > I have yet to digest the rest of the discussion, however:
> >
> > On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote:
> > > The LKMM uses the same CAT
On Mon, Jun 25, 2018 at 09:32:29AM +0200, Peter Zijlstra wrote:
>
> I have yet to digest the rest of the discussion, however:
>
> On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote:
> > The LKMM uses the same CAT code for acquire/release and lock/unlock.
> > (In essence, it considers a
On Mon, Jun 25, 2018 at 09:32:29AM +0200, Peter Zijlstra wrote:
>
> I have yet to digest the rest of the discussion, however:
>
> On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote:
> > The LKMM uses the same CAT code for acquire/release and lock/unlock.
> > (In essence, it considers a
On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will Deacon wrote:
> > > I think the second example would preclude us using LDAPR for load-acquire,
> I don't think it's a moot point. We want new architectures to implement
> acquire/release efficiently, and it's not unlikely that they will have
>
On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will Deacon wrote:
> > > I think the second example would preclude us using LDAPR for load-acquire,
> I don't think it's a moot point. We want new architectures to implement
> acquire/release efficiently, and it's not unlikely that they will have
>
I have yet to digest the rest of the discussion, however:
On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote:
> The LKMM uses the same CAT code for acquire/release and lock/unlock.
> (In essence, it considers a lock to be an acquire and an unlock to be a
> release; everything else
I have yet to digest the rest of the discussion, however:
On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote:
> The LKMM uses the same CAT code for acquire/release and lock/unlock.
> (In essence, it considers a lock to be an acquire and an unlock to be a
> release; everything else
On Fri, Jun 22, 2018 at 03:11:37PM -0400, Alan Stern wrote:
> On Fri, 22 Jun 2018, Will Deacon wrote:
> > On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote:
[ . . . ]
> > > > Could we drop the acquire/release stuff from the patch and limit this
> > > > change
> > > > to locking
On Fri, Jun 22, 2018 at 03:11:37PM -0400, Alan Stern wrote:
> On Fri, 22 Jun 2018, Will Deacon wrote:
> > On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote:
[ . . . ]
> > > > Could we drop the acquire/release stuff from the patch and limit this
> > > > change
> > > > to locking
On Fri, 22 Jun 2018, Andrea Parri wrote:
> On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > More than one kernel developer has expressed the opinion that the LKMM
> > should enforce ordering of writes by release-acquire chains and by
> > locking. In other words, given the
On Fri, 22 Jun 2018, Andrea Parri wrote:
> On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > More than one kernel developer has expressed the opinion that the LKMM
> > should enforce ordering of writes by release-acquire chains and by
> > locking. In other words, given the
On Fri, 22 Jun 2018, Will Deacon wrote:
> Hi Alan,
>
> On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote:
> > On Fri, 22 Jun 2018, Will Deacon wrote:
> > > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > > > More than one kernel developer has expressed the opinion that
On Fri, 22 Jun 2018, Will Deacon wrote:
> Hi Alan,
>
> On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote:
> > On Fri, 22 Jun 2018, Will Deacon wrote:
> > > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > > > More than one kernel developer has expressed the opinion that
Hi Alan,
On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote:
> On Fri, 22 Jun 2018, Will Deacon wrote:
> > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > > More than one kernel developer has expressed the opinion that the LKMM
> > > should enforce ordering of writes by
Hi Alan,
On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote:
> On Fri, 22 Jun 2018, Will Deacon wrote:
> > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > > More than one kernel developer has expressed the opinion that the LKMM
> > > should enforce ordering of writes by
On Fri, 22 Jun 2018, Will Deacon wrote:
> Hi Alan,
>
> On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > More than one kernel developer has expressed the opinion that the LKMM
> > should enforce ordering of writes by release-acquire chains and by
> > locking. In other words, given
On Fri, 22 Jun 2018, Will Deacon wrote:
> Hi Alan,
>
> On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > More than one kernel developer has expressed the opinion that the LKMM
> > should enforce ordering of writes by release-acquire chains and by
> > locking. In other words, given
On Fri, Jun 22, 2018 at 12:31:29PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 22, 2018 at 10:55:47AM +0100, Will Deacon wrote:
> > On Fri, Jun 22, 2018 at 09:09:28AM +0100, Will Deacon wrote:
> > > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > > > More than one kernel developer
On Fri, Jun 22, 2018 at 12:31:29PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 22, 2018 at 10:55:47AM +0100, Will Deacon wrote:
> > On Fri, Jun 22, 2018 at 09:09:28AM +0100, Will Deacon wrote:
> > > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > > > More than one kernel developer
> > > I also just realised that this prevents Power from using ctrl+isync to
> > > implement acquire, should they wish to do so.
> >
> > They in fact do so on chips lacking LWSYNC, see how PPC_ACQUIRE_BARRIER
> > (as used by atomic_*_acquire) turns into ISYNC (note however that they
> > do not
> > > I also just realised that this prevents Power from using ctrl+isync to
> > > implement acquire, should they wish to do so.
> >
> > They in fact do so on chips lacking LWSYNC, see how PPC_ACQUIRE_BARRIER
> > (as used by atomic_*_acquire) turns into ISYNC (note however that they
> > do not
Hi Peter,
On Fri, Jun 22, 2018 at 12:31:29PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 22, 2018 at 10:55:47AM +0100, Will Deacon wrote:
> > On Fri, Jun 22, 2018 at 09:09:28AM +0100, Will Deacon wrote:
> > > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > > > More than one kernel
Hi Peter,
On Fri, Jun 22, 2018 at 12:31:29PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 22, 2018 at 10:55:47AM +0100, Will Deacon wrote:
> > On Fri, Jun 22, 2018 at 09:09:28AM +0100, Will Deacon wrote:
> > > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > > > More than one kernel
On Fri, Jun 22, 2018 at 10:55:47AM +0100, Will Deacon wrote:
> On Fri, Jun 22, 2018 at 09:09:28AM +0100, Will Deacon wrote:
> > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > > More than one kernel developer has expressed the opinion that the LKMM
> > > should enforce ordering of
On Fri, Jun 22, 2018 at 10:55:47AM +0100, Will Deacon wrote:
> On Fri, Jun 22, 2018 at 09:09:28AM +0100, Will Deacon wrote:
> > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > > More than one kernel developer has expressed the opinion that the LKMM
> > > should enforce ordering of
On Fri, Jun 22, 2018 at 09:09:28AM +0100, Will Deacon wrote:
> On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > More than one kernel developer has expressed the opinion that the LKMM
> > should enforce ordering of writes by release-acquire chains and by
> > locking. In other words,
On Fri, Jun 22, 2018 at 09:09:28AM +0100, Will Deacon wrote:
> On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> > More than one kernel developer has expressed the opinion that the LKMM
> > should enforce ordering of writes by release-acquire chains and by
> > locking. In other words,
On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> More than one kernel developer has expressed the opinion that the LKMM
> should enforce ordering of writes by release-acquire chains and by
> locking. In other words, given the following code:
>
> WRITE_ONCE(x, 1);
>
On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote:
> More than one kernel developer has expressed the opinion that the LKMM
> should enforce ordering of writes by release-acquire chains and by
> locking. In other words, given the following code:
>
> WRITE_ONCE(x, 1);
>
1 - 100 of 108 matches
Mail list logo
