> On Fri, 20 Oct 2017, Reshetova, Elena wrote:
>
> > Since I am not really sure what to do with this futex patch, I will drop it
> > from the new series that I am about to send now.
> >
> > Please let me know what exactly should I do with this patch, as I wrote
> > previously I really don't
> On Fri, 20 Oct 2017, Reshetova, Elena wrote:
>
> > Since I am not really sure what to do with this futex patch, I will drop it
> > from the new series that I am about to send now.
> >
> > Please let me know what exactly should I do with this patch, as I wrote
> > previously I really don't
On Fri, 20 Oct 2017, Reshetova, Elena wrote:
> Since I am not really sure what to do with this futex patch, I will drop it
> from the new series that I am about to send now.
>
> Please let me know what exactly should I do with this patch, as I wrote
> previously I really don't understand.
As
On Fri, 20 Oct 2017, Reshetova, Elena wrote:
> Since I am not really sure what to do with this futex patch, I will drop it
> from the new series that I am about to send now.
>
> Please let me know what exactly should I do with this patch, as I wrote
> previously I really don't understand.
As
Since I am not really sure what to do with this futex patch, I will drop it
from the new series that I am about to send now.
Please let me know what exactly should I do with this patch, as I wrote
previously I really don't understand.
Best Regards,
Elena.
> Sorry for delayed reply.
>
> > On
Since I am not really sure what to do with this futex patch, I will drop it
from the new series that I am about to send now.
Please let me know what exactly should I do with this patch, as I wrote
previously I really don't understand.
Best Regards,
Elena.
> Sorry for delayed reply.
>
> > On
Sorry for delayed reply.
> On Mon, Sep 04, 2017 at 10:31:54AM +, Reshetova, Elena wrote:
> > > > But can they make "fast" implementation on ARM that would give stronger
> > > > memory guarantees?
> > >
> > > Whatever for?
> >
> > Well, maybe just by default when arch.-specific implementation
Sorry for delayed reply.
> On Mon, Sep 04, 2017 at 10:31:54AM +, Reshetova, Elena wrote:
> > > > But can they make "fast" implementation on ARM that would give stronger
> > > > memory guarantees?
> > >
> > > Whatever for?
> >
> > Well, maybe just by default when arch.-specific implementation
On Mon, Sep 04, 2017 at 10:31:54AM +, Reshetova, Elena wrote:
> > > But can they make "fast" implementation on ARM that would give stronger
> > > memory guarantees?
> >
> > Whatever for?
>
> Well, maybe just by default when arch.-specific implementation is
> done. But I was just trying to
On Mon, Sep 04, 2017 at 10:31:54AM +, Reshetova, Elena wrote:
> > > But can they make "fast" implementation on ARM that would give stronger
> > > memory guarantees?
> >
> > Whatever for?
>
> Well, maybe just by default when arch.-specific implementation is
> done. But I was just trying to
eesc...@chromium.org; dvh...@infradead.org; ebied...@xmission.com
> Subject: Re: [PATCH 14/15] futex: convert futex_pi_state.refcount to
> refcount_t
>
> On Fri, Sep 01, 2017 at 05:03:55PM +, Reshetova, Elena wrote:
> > > On Fri, Sep 01, 2017 at 01:24:16PM +, Reshetov
n.com
> Subject: Re: [PATCH 14/15] futex: convert futex_pi_state.refcount to
> refcount_t
>
> On Fri, Sep 01, 2017 at 05:03:55PM +, Reshetova, Elena wrote:
> > > On Fri, Sep 01, 2017 at 01:24:16PM +, Reshetova, Elena wrote:
> > > >
> > &
On Fri, Sep 01, 2017 at 05:03:55PM +, Reshetova, Elena wrote:
> > On Fri, Sep 01, 2017 at 01:24:16PM +, Reshetova, Elena wrote:
> > >
> > > > On Fri, Sep 01, 2017 at 11:05:33AM +, Reshetova, Elena wrote:
> > > > > Actually on the second thought: does the above memory ordering
> > > >
On Fri, Sep 01, 2017 at 05:03:55PM +, Reshetova, Elena wrote:
> > On Fri, Sep 01, 2017 at 01:24:16PM +, Reshetova, Elena wrote:
> > >
> > > > On Fri, Sep 01, 2017 at 11:05:33AM +, Reshetova, Elena wrote:
> > > > > Actually on the second thought: does the above memory ordering
> > > >
> On Fri, Sep 01, 2017 at 01:24:16PM +, Reshetova, Elena wrote:
> >
> > > On Fri, Sep 01, 2017 at 11:05:33AM +, Reshetova, Elena wrote:
> > > > Actually on the second thought: does the above memory ordering
> > > > differences
> > > > really apply when we have ARCH_HAS_REFCOUNT? To me it
> On Fri, Sep 01, 2017 at 01:24:16PM +, Reshetova, Elena wrote:
> >
> > > On Fri, Sep 01, 2017 at 11:05:33AM +, Reshetova, Elena wrote:
> > > > Actually on the second thought: does the above memory ordering
> > > > differences
> > > > really apply when we have ARCH_HAS_REFCOUNT? To me it
On Fri, Sep 01, 2017 at 01:24:16PM +, Reshetova, Elena wrote:
>
> > On Fri, Sep 01, 2017 at 11:05:33AM +, Reshetova, Elena wrote:
> > > Actually on the second thought: does the above memory ordering differences
> > > really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the
On Fri, Sep 01, 2017 at 01:24:16PM +, Reshetova, Elena wrote:
>
> > On Fri, Sep 01, 2017 at 11:05:33AM +, Reshetova, Elena wrote:
> > > Actually on the second thought: does the above memory ordering differences
> > > really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the
> On Fri, Sep 01, 2017 at 11:05:33AM +, Reshetova, Elena wrote:
> > Actually on the second thought: does the above memory ordering differences
> > really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the way
> > how it is currently implemented for x86 is the same way as it is for
> On Fri, Sep 01, 2017 at 11:05:33AM +, Reshetova, Elena wrote:
> > Actually on the second thought: does the above memory ordering differences
> > really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the way
> > how it is currently implemented for x86 is the same way as it is for
On Fri, Sep 01, 2017 at 11:05:33AM +, Reshetova, Elena wrote:
> Actually on the second thought: does the above memory ordering differences
> really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the way
> how it is currently implemented for x86 is the same way as it is for atomic
On Fri, Sep 01, 2017 at 11:05:33AM +, Reshetova, Elena wrote:
> Actually on the second thought: does the above memory ordering differences
> really apply when we have ARCH_HAS_REFCOUNT? To me it looks like the way
> how it is currently implemented for x86 is the same way as it is for atomic
> On Fri, 1 Sep 2017, Peter Zijlstra wrote:
> > > On Fri, Sep 01, 2017 at 09:39:50AM +0200, Thomas Gleixner wrote:
> > > > On Wed, 30 Aug 2017, Elena Reshetova wrote:
> > > > > atomic_t variables are currently used to implement reference
> > > > > counters with the following properties:
> > > > >
> On Fri, 1 Sep 2017, Peter Zijlstra wrote:
> > > On Fri, Sep 01, 2017 at 09:39:50AM +0200, Thomas Gleixner wrote:
> > > > On Wed, 30 Aug 2017, Elena Reshetova wrote:
> > > > > atomic_t variables are currently used to implement reference
> > > > > counters with the following properties:
> > > > >
> On Fri, 1 Sep 2017, Peter Zijlstra wrote:
> > On Fri, Sep 01, 2017 at 09:39:50AM +0200, Thomas Gleixner wrote:
> > > On Wed, 30 Aug 2017, Elena Reshetova wrote:
> > > > atomic_t variables are currently used to implement reference
> > > > counters with the following properties:
> > > > - counter
> On Fri, 1 Sep 2017, Peter Zijlstra wrote:
> > On Fri, Sep 01, 2017 at 09:39:50AM +0200, Thomas Gleixner wrote:
> > > On Wed, 30 Aug 2017, Elena Reshetova wrote:
> > > > atomic_t variables are currently used to implement reference
> > > > counters with the following properties:
> > > > - counter
On Fri, 1 Sep 2017, Peter Zijlstra wrote:
> On Fri, Sep 01, 2017 at 09:39:50AM +0200, Thomas Gleixner wrote:
> > On Wed, 30 Aug 2017, Elena Reshetova wrote:
> > > atomic_t variables are currently used to implement reference
> > > counters with the following properties:
> > > - counter is
On Fri, 1 Sep 2017, Peter Zijlstra wrote:
> On Fri, Sep 01, 2017 at 09:39:50AM +0200, Thomas Gleixner wrote:
> > On Wed, 30 Aug 2017, Elena Reshetova wrote:
> > > atomic_t variables are currently used to implement reference
> > > counters with the following properties:
> > > - counter is
On Fri, Sep 01, 2017 at 09:39:50AM +0200, Thomas Gleixner wrote:
> On Wed, 30 Aug 2017, Elena Reshetova wrote:
> > atomic_t variables are currently used to implement reference
> > counters with the following properties:
> > - counter is initialized to 1 using atomic_set()
> > - a resource is
On Fri, Sep 01, 2017 at 09:39:50AM +0200, Thomas Gleixner wrote:
> On Wed, 30 Aug 2017, Elena Reshetova wrote:
> > atomic_t variables are currently used to implement reference
> > counters with the following properties:
> > - counter is initialized to 1 using atomic_set()
> > - a resource is
On Wed, 30 Aug 2017, Elena Reshetova wrote:
> atomic_t variables are currently used to implement reference
> counters with the following properties:
> - counter is initialized to 1 using atomic_set()
> - a resource is freed upon counter reaching zero
> - once counter reaches zero, its further
>
On Wed, 30 Aug 2017, Elena Reshetova wrote:
> atomic_t variables are currently used to implement reference
> counters with the following properties:
> - counter is initialized to 1 using atomic_set()
> - a resource is freed upon counter reaching zero
> - once counter reaches zero, its further
>
32 matches
Mail list logo
