On Thu, Nov 16, 2017 at 02:44:30PM +0100, Michal Hocko wrote:
> On Mon 13-11-17 09:09:57, Reshetova, Elena wrote:
> >
> >
> > > Note that there's work done on better documents and updates to this one.
> > > One document that might be good to read (I have not in fact had time to
> > > read it
On Thu, Nov 16, 2017 at 02:44:30PM +0100, Michal Hocko wrote:
> On Mon 13-11-17 09:09:57, Reshetova, Elena wrote:
> >
> >
> > > Note that there's work done on better documents and updates to this one.
> > > One document that might be good to read (I have not in fact had time to
> > > read it
On Mon 13-11-17 09:09:57, Reshetova, Elena wrote:
>
>
> > Note that there's work done on better documents and updates to this one.
> > One document that might be good to read (I have not in fact had time to
> > read it myself yet :-():
> >
> > https://github.com/aparri/memory-
> >
On Mon 13-11-17 09:09:57, Reshetova, Elena wrote:
>
>
> > Note that there's work done on better documents and updates to this one.
> > One document that might be good to read (I have not in fact had time to
> > read it myself yet :-():
> >
> > https://github.com/aparri/memory-
> >
On Thu, Nov 16, 2017 at 09:58:04AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 15, 2017 at 10:01:11PM +0100, Andrea Parri wrote:
>
> > > And in specific things like:
> > >
> > > 135e8c9250dd5
> > > ecf7d01c229d1
> > >
> > > which use the release of rq->lock paired with the next acquire of
On Thu, Nov 16, 2017 at 09:58:04AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 15, 2017 at 10:01:11PM +0100, Andrea Parri wrote:
>
> > > And in specific things like:
> > >
> > > 135e8c9250dd5
> > > ecf7d01c229d1
> > >
> > > which use the release of rq->lock paired with the next acquire of
On Wed, Nov 15, 2017 at 10:01:11PM +0100, Andrea Parri wrote:
> > And in specific things like:
> >
> > 135e8c9250dd5
> > ecf7d01c229d1
> >
> > which use the release of rq->lock paired with the next acquire of the
> > same rq->lock to match with an smp_rmb().
>
> Those cycles are currently
On Wed, Nov 15, 2017 at 10:01:11PM +0100, Andrea Parri wrote:
> > And in specific things like:
> >
> > 135e8c9250dd5
> > ecf7d01c229d1
> >
> > which use the release of rq->lock paired with the next acquire of the
> > same rq->lock to match with an smp_rmb().
>
> Those cycles are currently
On Wed, Nov 15, 2017 at 03:22:33PM -0500, Alan Stern wrote:
> You know, sometimes I feel like I'm losing my mind.
Hehe, I'm very familiar with that feeling ;-)
On Wed, Nov 15, 2017 at 03:22:33PM -0500, Alan Stern wrote:
> You know, sometimes I feel like I'm losing my mind.
Hehe, I'm very familiar with that feeling ;-)
On Wed, Nov 15, 2017 at 09:03:07PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 15, 2017 at 02:15:19PM -0500, Alan Stern wrote:
> > On Wed, 15 Nov 2017, Will Deacon wrote:
> >
> > > On Thu, Nov 02, 2017 at 04:21:56PM -0400, Alan Stern wrote:
> > > > I was trying to think of something completely
On Wed, Nov 15, 2017 at 09:03:07PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 15, 2017 at 02:15:19PM -0500, Alan Stern wrote:
> > On Wed, 15 Nov 2017, Will Deacon wrote:
> >
> > > On Thu, Nov 02, 2017 at 04:21:56PM -0400, Alan Stern wrote:
> > > > I was trying to think of something completely
On Wed, 15 Nov 2017, Peter Zijlstra wrote:
> On Wed, Nov 15, 2017 at 02:15:19PM -0500, Alan Stern wrote:
> > On Wed, 15 Nov 2017, Will Deacon wrote:
> >
> > > On Thu, Nov 02, 2017 at 04:21:56PM -0400, Alan Stern wrote:
> > > > I was trying to think of something completely different. If you have
On Wed, 15 Nov 2017, Peter Zijlstra wrote:
> On Wed, Nov 15, 2017 at 02:15:19PM -0500, Alan Stern wrote:
> > On Wed, 15 Nov 2017, Will Deacon wrote:
> >
> > > On Thu, Nov 02, 2017 at 04:21:56PM -0400, Alan Stern wrote:
> > > > I was trying to think of something completely different. If you have
On Wed, Nov 15, 2017 at 02:15:19PM -0500, Alan Stern wrote:
> On Wed, 15 Nov 2017, Will Deacon wrote:
>
> > On Thu, Nov 02, 2017 at 04:21:56PM -0400, Alan Stern wrote:
> > > I was trying to think of something completely different. If you have a
> > > release/acquire to the same address, it
On Wed, Nov 15, 2017 at 02:15:19PM -0500, Alan Stern wrote:
> On Wed, 15 Nov 2017, Will Deacon wrote:
>
> > On Thu, Nov 02, 2017 at 04:21:56PM -0400, Alan Stern wrote:
> > > I was trying to think of something completely different. If you have a
> > > release/acquire to the same address, it
On Wed, 15 Nov 2017, Will Deacon wrote:
> On Thu, Nov 02, 2017 at 04:21:56PM -0400, Alan Stern wrote:
> > I was trying to think of something completely different. If you have a
> > release/acquire to the same address, it creates a happens-before
> > ordering:
> >
> > Access x
> >
On Wed, 15 Nov 2017, Will Deacon wrote:
> On Thu, Nov 02, 2017 at 04:21:56PM -0400, Alan Stern wrote:
> > I was trying to think of something completely different. If you have a
> > release/acquire to the same address, it creates a happens-before
> > ordering:
> >
> > Access x
> >
On Thu, Nov 02, 2017 at 04:21:56PM -0400, Alan Stern wrote:
> I was trying to think of something completely different. If you have a
> release/acquire to the same address, it creates a happens-before
> ordering:
>
> Access x
> Release a
> Acquire a
> Access y
>
> Here is
On Thu, Nov 02, 2017 at 04:21:56PM -0400, Alan Stern wrote:
> I was trying to think of something completely different. If you have a
> release/acquire to the same address, it creates a happens-before
> ordering:
>
> Access x
> Release a
> Acquire a
> Access y
>
> Here is
On Tue, Nov 14, 2017 at 11:23:53AM +, Reshetova, Elena wrote:
> > On Mon, Nov 13, 2017 at 04:01:11PM +, Reshetova, Elena wrote:
> > >
> > > > On Mon, Nov 13, 2017 at 09:09:57AM +, Reshetova, Elena wrote:
> > > > >
> > > > >
> > > > > > Note that there's work done on better documents
On Tue, Nov 14, 2017 at 11:23:53AM +, Reshetova, Elena wrote:
> > On Mon, Nov 13, 2017 at 04:01:11PM +, Reshetova, Elena wrote:
> > >
> > > > On Mon, Nov 13, 2017 at 09:09:57AM +, Reshetova, Elena wrote:
> > > > >
> > > > >
> > > > > > Note that there's work done on better documents
> On Mon, Nov 13, 2017 at 04:01:11PM +, Reshetova, Elena wrote:
> >
> > > On Mon, Nov 13, 2017 at 09:09:57AM +, Reshetova, Elena wrote:
> > > >
> > > >
> > > > > Note that there's work done on better documents and updates to this
> > > > > one.
> > > > > One document that might be good
> On Mon, Nov 13, 2017 at 04:01:11PM +, Reshetova, Elena wrote:
> >
> > > On Mon, Nov 13, 2017 at 09:09:57AM +, Reshetova, Elena wrote:
> > > >
> > > >
> > > > > Note that there's work done on better documents and updates to this
> > > > > one.
> > > > > One document that might be good
On Mon, Nov 13, 2017 at 04:01:11PM +, Reshetova, Elena wrote:
>
> > On Mon, Nov 13, 2017 at 09:09:57AM +, Reshetova, Elena wrote:
> > >
> > >
> > > > Note that there's work done on better documents and updates to this one.
> > > > One document that might be good to read (I have not in
On Mon, Nov 13, 2017 at 04:01:11PM +, Reshetova, Elena wrote:
>
> > On Mon, Nov 13, 2017 at 09:09:57AM +, Reshetova, Elena wrote:
> > >
> > >
> > > > Note that there's work done on better documents and updates to this one.
> > > > One document that might be good to read (I have not in
> On Mon, Nov 13, 2017 at 09:09:57AM +, Reshetova, Elena wrote:
> >
> >
> > > Note that there's work done on better documents and updates to this one.
> > > One document that might be good to read (I have not in fact had time to
> > > read it myself yet :-():
> > >
> > >
> On Mon, Nov 13, 2017 at 09:09:57AM +, Reshetova, Elena wrote:
> >
> >
> > > Note that there's work done on better documents and updates to this one.
> > > One document that might be good to read (I have not in fact had time to
> > > read it myself yet :-():
> > >
> > >
On Mon, Nov 13, 2017 at 09:09:57AM +, Reshetova, Elena wrote:
>
>
> > Note that there's work done on better documents and updates to this one.
> > One document that might be good to read (I have not in fact had time to
> > read it myself yet :-():
> >
> > https://github.com/aparri/memory-
On Mon, Nov 13, 2017 at 09:09:57AM +, Reshetova, Elena wrote:
>
>
> > Note that there's work done on better documents and updates to this one.
> > One document that might be good to read (I have not in fact had time to
> > read it myself yet :-():
> >
> > https://github.com/aparri/memory-
> Note that there's work done on better documents and updates to this one.
> One document that might be good to read (I have not in fact had time to
> read it myself yet :-():
>
> https://github.com/aparri/memory-
> model/blob/master/Documentation/explanation.txt
>
I have just finished
> Note that there's work done on better documents and updates to this one.
> One document that might be good to read (I have not in fact had time to
> read it myself yet :-():
>
> https://github.com/aparri/memory-
> model/blob/master/Documentation/explanation.txt
>
I have just finished
> On Thu, Nov 02, 2017 at 11:04:53AM +, Reshetova, Elena wrote:
>
> > Well refcount_dec_and_test() is not the only function that has different
> > memory ordering specifics. So, the full answer then for any arbitrary case
> > according to your points above would be smth like:
> >
> > for
> On Thu, Nov 02, 2017 at 11:04:53AM +, Reshetova, Elena wrote:
>
> > Well refcount_dec_and_test() is not the only function that has different
> > memory ordering specifics. So, the full answer then for any arbitrary case
> > according to your points above would be smth like:
> >
> > for
On Thu, 2 Nov 2017, Andrea Parri wrote:
> > This is forbidden. It would remain forbidden even if the smp_mb in P1
> > were replaced by a similar release/acquire pair for the same memory
> > location.
>
> Hopefully, the LKMM does not agree with this assessment... ;-)
No, it doesn't.
> Here's
On Thu, 2 Nov 2017, Andrea Parri wrote:
> > This is forbidden. It would remain forbidden even if the smp_mb in P1
> > were replaced by a similar release/acquire pair for the same memory
> > location.
>
> Hopefully, the LKMM does not agree with this assessment... ;-)
No, it doesn't.
> Here's
On Thu, 2 Nov 2017, Will Deacon wrote:
> > Right. To address your point: release + acquire isn't the same as a
> > full barrier either. The SB pattern illustrates the difference:
> >
> > P0 P1
> > Write x=1 Write y=1
> > Release a smp_mb
> > Acquire b
On Thu, 2 Nov 2017, Will Deacon wrote:
> > Right. To address your point: release + acquire isn't the same as a
> > full barrier either. The SB pattern illustrates the difference:
> >
> > P0 P1
> > Write x=1 Write y=1
> > Release a smp_mb
> > Acquire b
On Thu, Nov 02, 2017 at 01:08:52PM -0400, Alan Stern wrote:
> On Thu, 2 Nov 2017, Peter Zijlstra wrote:
>
> > On Thu, Nov 02, 2017 at 11:40:35AM -0400, Alan Stern wrote:
> > > On Thu, 2 Nov 2017, Peter Zijlstra wrote:
> > >
> > > > > Lock functions such as refcount_dec_and_lock() &
> > > > >
On Thu, Nov 02, 2017 at 01:08:52PM -0400, Alan Stern wrote:
> On Thu, 2 Nov 2017, Peter Zijlstra wrote:
>
> > On Thu, Nov 02, 2017 at 11:40:35AM -0400, Alan Stern wrote:
> > > On Thu, 2 Nov 2017, Peter Zijlstra wrote:
> > >
> > > > > Lock functions such as refcount_dec_and_lock() &
> > > > >
On Thu, Nov 02, 2017 at 05:16:44PM +, Will Deacon wrote:
> On Thu, Nov 02, 2017 at 01:08:52PM -0400, Alan Stern wrote:
> > Right. To address your point: release + acquire isn't the same as a
> > full barrier either. The SB pattern illustrates the difference:
> >
> > P0 P1
On Thu, Nov 02, 2017 at 05:16:44PM +, Will Deacon wrote:
> On Thu, Nov 02, 2017 at 01:08:52PM -0400, Alan Stern wrote:
> > Right. To address your point: release + acquire isn't the same as a
> > full barrier either. The SB pattern illustrates the difference:
> >
> > P0 P1
On Thu, Nov 02, 2017 at 01:08:52PM -0400, Alan Stern wrote:
> On Thu, 2 Nov 2017, Peter Zijlstra wrote:
>
> > On Thu, Nov 02, 2017 at 11:40:35AM -0400, Alan Stern wrote:
> > > On Thu, 2 Nov 2017, Peter Zijlstra wrote:
> > >
> > > > > Lock functions such as refcount_dec_and_lock() &
> > > > >
On Thu, Nov 02, 2017 at 01:08:52PM -0400, Alan Stern wrote:
> On Thu, 2 Nov 2017, Peter Zijlstra wrote:
>
> > On Thu, Nov 02, 2017 at 11:40:35AM -0400, Alan Stern wrote:
> > > On Thu, 2 Nov 2017, Peter Zijlstra wrote:
> > >
> > > > > Lock functions such as refcount_dec_and_lock() &
> > > > >
On Thu, 2 Nov 2017, Peter Zijlstra wrote:
> On Thu, Nov 02, 2017 at 11:40:35AM -0400, Alan Stern wrote:
> > On Thu, 2 Nov 2017, Peter Zijlstra wrote:
> >
> > > > Lock functions such as refcount_dec_and_lock() &
> > > > refcount_dec_and_mutex_lock() Provide exactly the same guarantees as
> > > >
On Thu, 2 Nov 2017, Peter Zijlstra wrote:
> On Thu, Nov 02, 2017 at 11:40:35AM -0400, Alan Stern wrote:
> > On Thu, 2 Nov 2017, Peter Zijlstra wrote:
> >
> > > > Lock functions such as refcount_dec_and_lock() &
> > > > refcount_dec_and_mutex_lock() Provide exactly the same guarantees as
> > > >
On Thu, Nov 02, 2017 at 05:02:37PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 02, 2017 at 11:40:35AM -0400, Alan Stern wrote:
> > On Thu, 2 Nov 2017, Peter Zijlstra wrote:
> >
> > > > Lock functions such as refcount_dec_and_lock() &
> > > > refcount_dec_and_mutex_lock() Provide exactly the same
On Thu, Nov 02, 2017 at 05:02:37PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 02, 2017 at 11:40:35AM -0400, Alan Stern wrote:
> > On Thu, 2 Nov 2017, Peter Zijlstra wrote:
> >
> > > > Lock functions such as refcount_dec_and_lock() &
> > > > refcount_dec_and_mutex_lock() Provide exactly the same
On Thu, Nov 02, 2017 at 11:40:35AM -0400, Alan Stern wrote:
> On Thu, 2 Nov 2017, Peter Zijlstra wrote:
>
> > > Lock functions such as refcount_dec_and_lock() &
> > > refcount_dec_and_mutex_lock() Provide exactly the same guarantees as
> > > they atomic counterparts.
> >
> > Nope. The
On Thu, Nov 02, 2017 at 11:40:35AM -0400, Alan Stern wrote:
> On Thu, 2 Nov 2017, Peter Zijlstra wrote:
>
> > > Lock functions such as refcount_dec_and_lock() &
> > > refcount_dec_and_mutex_lock() Provide exactly the same guarantees as
> > > they atomic counterparts.
> >
> > Nope. The
On Thu, 2 Nov 2017, Peter Zijlstra wrote:
> > Lock functions such as refcount_dec_and_lock() &
> > refcount_dec_and_mutex_lock() Provide exactly the same guarantees as
> > they atomic counterparts.
>
> Nope. The atomic_dec_and_lock() provides smp_mb() while
> refcount_dec_and_lock() merely
On Thu, 2 Nov 2017, Peter Zijlstra wrote:
> > Lock functions such as refcount_dec_and_lock() &
> > refcount_dec_and_mutex_lock() Provide exactly the same guarantees as
> > they atomic counterparts.
>
> Nope. The atomic_dec_and_lock() provides smp_mb() while
> refcount_dec_and_lock() merely
On Thu, Nov 02, 2017 at 11:04:53AM +, Reshetova, Elena wrote:
> Well refcount_dec_and_test() is not the only function that has different
> memory ordering specifics. So, the full answer then for any arbitrary case
> according to your points above would be smth like:
>
> for each substituted
On Thu, Nov 02, 2017 at 11:04:53AM +, Reshetova, Elena wrote:
> Well refcount_dec_and_test() is not the only function that has different
> memory ordering specifics. So, the full answer then for any arbitrary case
> according to your points above would be smth like:
>
> for each substituted
Sorry for delayed reply, but I was actually reading and trying to understand
all the involved notions, so it took a while...
> On Fri, Oct 27, 2017 at 06:49:55AM +, Reshetova, Elena wrote:
> > Could we possibly have a bit more elaborate discussion on this?
> >
> > Or alternatively, what then
Sorry for delayed reply, but I was actually reading and trying to understand
all the involved notions, so it took a while...
> On Fri, Oct 27, 2017 at 06:49:55AM +, Reshetova, Elena wrote:
> > Could we possibly have a bit more elaborate discussion on this?
> >
> > Or alternatively, what then
On Fri, Oct 27, 2017 at 06:49:55AM +, Reshetova, Elena wrote:
> Could we possibly have a bit more elaborate discussion on this?
>
> Or alternatively, what then should be the correct way for a certain
> variable (that behaves like a standard refcounter) to check if the
> relaxed memory
On Fri, Oct 27, 2017 at 06:49:55AM +, Reshetova, Elena wrote:
> Could we possibly have a bit more elaborate discussion on this?
>
> Or alternatively, what then should be the correct way for a certain
> variable (that behaves like a standard refcounter) to check if the
> relaxed memory
> On Mon, Oct 23, 2017 at 02:09:44PM +0300, Elena Reshetova wrote:
> > Currently arch. independent implementation of refcount_t in
> > lib/refcount.c provides weak memory ordering guarantees
> > compare to its analog atomic_t implementations.
> > While it should not be a problem for most of the
> On Mon, Oct 23, 2017 at 02:09:44PM +0300, Elena Reshetova wrote:
> > Currently arch. independent implementation of refcount_t in
> > lib/refcount.c provides weak memory ordering guarantees
> > compare to its analog atomic_t implementations.
> > While it should not be a problem for most of the
On Mon, Oct 23, 2017 at 02:09:44PM +0300, Elena Reshetova wrote:
> Currently arch. independent implementation of refcount_t in
> lib/refcount.c provides weak memory ordering guarantees
> compare to its analog atomic_t implementations.
> While it should not be a problem for most of the actual
>
On Mon, Oct 23, 2017 at 02:09:44PM +0300, Elena Reshetova wrote:
> Currently arch. independent implementation of refcount_t in
> lib/refcount.c provides weak memory ordering guarantees
> compare to its analog atomic_t implementations.
> While it should not be a problem for most of the actual
>
62 matches
Mail list logo
