On Thu, Mar 21, 2013 at 03:56:58PM -0700, Eric Dumazet wrote:
> On Thu, 2013-03-21 at 19:30 +0100, Oleg Nesterov wrote:
>
> > To me, it would be better to kill atomic_inc_not_zero_hint() or unify
> > unify it with atomic_inc_not_zero(). But this is another story.
>
> git is your friend.
>
> I
On 03/21, Eric Dumazet wrote:
>
> On Thu, 2013-03-21 at 19:30 +0100, Oleg Nesterov wrote:
>
> > To me, it would be better to kill atomic_inc_not_zero_hint() or unify
> > unify it with atomic_inc_not_zero(). But this is another story.
>
> git is your friend.
>
> I suggest you read 3f9d35b9514
On 03/21, Eric Dumazet wrote:
On Thu, 2013-03-21 at 19:30 +0100, Oleg Nesterov wrote:
To me, it would be better to kill atomic_inc_not_zero_hint() or unify
unify it with atomic_inc_not_zero(). But this is another story.
git is your friend.
I suggest you read 3f9d35b9514 changelog before
On Thu, Mar 21, 2013 at 03:56:58PM -0700, Eric Dumazet wrote:
On Thu, 2013-03-21 at 19:30 +0100, Oleg Nesterov wrote:
To me, it would be better to kill atomic_inc_not_zero_hint() or unify
unify it with atomic_inc_not_zero(). But this is another story.
git is your friend.
I suggest you
On Thu, 2013-03-21 at 19:30 +0100, Oleg Nesterov wrote:
> To me, it would be better to kill atomic_inc_not_zero_hint() or unify
> unify it with atomic_inc_not_zero(). But this is another story.
git is your friend.
I suggest you read 3f9d35b9514 changelog before killing it, thanks.
--
To
On 03/21, Eric Dumazet wrote:
>
> On Thu, 2013-03-21 at 18:08 +0100, Oleg Nesterov wrote:
>
> > OK... since nobody volunteered to make a patch, what do you think about
> > the change below?
> >
> > It should "fix" atomic_add_unless() (only on x86) and optimize
> > atomic_inc/dec_unless.
> >
> >
On Thu, 2013-03-21 at 18:08 +0100, Oleg Nesterov wrote:
> OK... since nobody volunteered to make a patch, what do you think about
> the change below?
>
> It should "fix" atomic_add_unless() (only on x86) and optimize
> atomic_inc/dec_unless.
>
> With this change atomic_*_unless() can do the
On Thu, Mar 21, 2013 at 06:08:27PM +0100, Oleg Nesterov wrote:
> On 03/17, Paul E. McKenney wrote:
> >
> > On Sat, Mar 16, 2013 at 07:30:22PM +0100, Oleg Nesterov wrote:
> > >
> > > > The rule is that if an atomic primitive returns non-void, then there is
> > > > a full memory barrier before and
On 03/17, Paul E. McKenney wrote:
>
> On Sat, Mar 16, 2013 at 07:30:22PM +0100, Oleg Nesterov wrote:
> >
> > > The rule is that if an atomic primitive returns non-void, then there is
> > > a full memory barrier before and after.
> >
> > This case is documented...
> >
> > > This applies to
On 03/17, Paul E. McKenney wrote:
On Sat, Mar 16, 2013 at 07:30:22PM +0100, Oleg Nesterov wrote:
The rule is that if an atomic primitive returns non-void, then there is
a full memory barrier before and after.
This case is documented...
This applies to primitives
returning
On Thu, Mar 21, 2013 at 06:08:27PM +0100, Oleg Nesterov wrote:
On 03/17, Paul E. McKenney wrote:
On Sat, Mar 16, 2013 at 07:30:22PM +0100, Oleg Nesterov wrote:
The rule is that if an atomic primitive returns non-void, then there is
a full memory barrier before and after.
This
On Thu, 2013-03-21 at 18:08 +0100, Oleg Nesterov wrote:
OK... since nobody volunteered to make a patch, what do you think about
the change below?
It should fix atomic_add_unless() (only on x86) and optimize
atomic_inc/dec_unless.
With this change atomic_*_unless() can do the unnecessary
On 03/21, Eric Dumazet wrote:
On Thu, 2013-03-21 at 18:08 +0100, Oleg Nesterov wrote:
OK... since nobody volunteered to make a patch, what do you think about
the change below?
It should fix atomic_add_unless() (only on x86) and optimize
atomic_inc/dec_unless.
With this change
On Thu, 2013-03-21 at 19:30 +0100, Oleg Nesterov wrote:
To me, it would be better to kill atomic_inc_not_zero_hint() or unify
unify it with atomic_inc_not_zero(). But this is another story.
git is your friend.
I suggest you read 3f9d35b9514 changelog before killing it, thanks.
--
To
On Sat, Mar 16, 2013 at 07:30:22PM +0100, Oleg Nesterov wrote:
> On 03/15, Paul E. McKenney wrote:
> >
> > On Fri, Mar 15, 2013 at 07:34:32PM +0100, Frederic Weisbecker wrote:
> > > 2013/3/15 Oleg Nesterov :
> > > >
> > > > My point was: should we fix atomic_add_unless() then? If not, why
> > > >
On Sat, Mar 16, 2013 at 07:30:22PM +0100, Oleg Nesterov wrote:
On 03/15, Paul E. McKenney wrote:
On Fri, Mar 15, 2013 at 07:34:32PM +0100, Frederic Weisbecker wrote:
2013/3/15 Oleg Nesterov o...@redhat.com:
My point was: should we fix atomic_add_unless() then? If not, why
On 03/15, Paul E. McKenney wrote:
>
> On Fri, Mar 15, 2013 at 07:34:32PM +0100, Frederic Weisbecker wrote:
> > 2013/3/15 Oleg Nesterov :
> > >
> > > My point was: should we fix atomic_add_unless() then? If not, why
> > > should atomic_add_unless_negative() differ?
> >
> > They shouldn't differ I
On 03/15, Frederic Weisbecker wrote:
>
> 2013/3/15 Oleg Nesterov :
> >
> > do_something() looks fine, if atomic_add_unless_negative() succeeds
> > we do have a barrier?
>
> Ok, I guess the guarantee of a barrier in case of failure is probably
> not needed. But since the only way to safely read the
On 03/15, Frederic Weisbecker wrote:
2013/3/15 Oleg Nesterov o...@redhat.com:
do_something() looks fine, if atomic_add_unless_negative() succeeds
we do have a barrier?
Ok, I guess the guarantee of a barrier in case of failure is probably
not needed. But since the only way to safely read
On 03/15, Paul E. McKenney wrote:
On Fri, Mar 15, 2013 at 07:34:32PM +0100, Frederic Weisbecker wrote:
2013/3/15 Oleg Nesterov o...@redhat.com:
My point was: should we fix atomic_add_unless() then? If not, why
should atomic_add_unless_negative() differ?
They shouldn't differ I
On Fri, Mar 15, 2013 at 07:34:32PM +0100, Frederic Weisbecker wrote:
> 2013/3/15 Oleg Nesterov :
> > On 03/15, Frederic Weisbecker wrote:
> >>
> >> > The lack of the barrier?
> >> >
> >> > I thought about this, this should be fine? atomic_add_unless() has the
> >> > same
> >> > "problem", but
2013/3/15 Oleg Nesterov :
> On 03/15, Frederic Weisbecker wrote:
>>
>> > The lack of the barrier?
>> >
>> > I thought about this, this should be fine? atomic_add_unless() has the same
>> > "problem", but this is documented in atomic_ops.txt:
>> >
>> > atomic_add_unless requires explicit
On 03/15, Frederic Weisbecker wrote:
>
> > The lack of the barrier?
> >
> > I thought about this, this should be fine? atomic_add_unless() has the same
> > "problem", but this is documented in atomic_ops.txt:
> >
> > atomic_add_unless requires explicit memory barriers around the
> >
2013/3/15 Oleg Nesterov :
> On 03/15, Ming Lei wrote:
>>
>> On Fri, Mar 15, 2013 at 9:46 PM, Oleg Nesterov wrote:
>> > On 03/15, Ming Lei wrote:
>> >>
>> >> On Fri, Mar 15, 2013 at 12:24 AM, Oleg Nesterov wrote:
>> >> > static inline int atomic_inc_unless_negative(atomic_t *p)
>> >> > {
>> >>
On 03/15, Ming Lei wrote:
>
> On Fri, Mar 15, 2013 at 9:46 PM, Oleg Nesterov wrote:
> > On 03/15, Ming Lei wrote:
> >>
> >> On Fri, Mar 15, 2013 at 12:24 AM, Oleg Nesterov wrote:
> >> > static inline int atomic_inc_unless_negative(atomic_t *p)
> >> > {
> >> > int v, v1;
> >> > -
On Fri, Mar 15, 2013 at 9:46 PM, Oleg Nesterov wrote:
> On 03/15, Ming Lei wrote:
>>
>> On Fri, Mar 15, 2013 at 12:24 AM, Oleg Nesterov wrote:
>> > static inline int atomic_inc_unless_negative(atomic_t *p)
>> > {
>> > int v, v1;
>> > - for (v = 0; v >= 0; v = v1) {
>> > +
On 03/15, Ming Lei wrote:
>
> On Fri, Mar 15, 2013 at 12:24 AM, Oleg Nesterov wrote:
> > static inline int atomic_inc_unless_negative(atomic_t *p)
> > {
> > int v, v1;
> > - for (v = 0; v >= 0; v = v1) {
> > + for (v = atomic_read(p); v >= 0; v = v1) {
> > v1
On 03/15, Ming Lei wrote:
On Fri, Mar 15, 2013 at 12:24 AM, Oleg Nesterov o...@redhat.com wrote:
static inline int atomic_inc_unless_negative(atomic_t *p)
{
int v, v1;
- for (v = 0; v = 0; v = v1) {
+ for (v = atomic_read(p); v = 0; v = v1) {
v1
On Fri, Mar 15, 2013 at 9:46 PM, Oleg Nesterov o...@redhat.com wrote:
On 03/15, Ming Lei wrote:
On Fri, Mar 15, 2013 at 12:24 AM, Oleg Nesterov o...@redhat.com wrote:
static inline int atomic_inc_unless_negative(atomic_t *p)
{
int v, v1;
- for (v = 0; v = 0; v = v1) {
On 03/15, Ming Lei wrote:
On Fri, Mar 15, 2013 at 9:46 PM, Oleg Nesterov o...@redhat.com wrote:
On 03/15, Ming Lei wrote:
On Fri, Mar 15, 2013 at 12:24 AM, Oleg Nesterov o...@redhat.com wrote:
static inline int atomic_inc_unless_negative(atomic_t *p)
{
int v, v1;
-
2013/3/15 Oleg Nesterov o...@redhat.com:
On 03/15, Ming Lei wrote:
On Fri, Mar 15, 2013 at 9:46 PM, Oleg Nesterov o...@redhat.com wrote:
On 03/15, Ming Lei wrote:
On Fri, Mar 15, 2013 at 12:24 AM, Oleg Nesterov o...@redhat.com wrote:
static inline int
On 03/15, Frederic Weisbecker wrote:
The lack of the barrier?
I thought about this, this should be fine? atomic_add_unless() has the same
problem, but this is documented in atomic_ops.txt:
atomic_add_unless requires explicit memory barriers around the
operation
2013/3/15 Oleg Nesterov o...@redhat.com:
On 03/15, Frederic Weisbecker wrote:
The lack of the barrier?
I thought about this, this should be fine? atomic_add_unless() has the same
problem, but this is documented in atomic_ops.txt:
atomic_add_unless requires explicit memory
On Fri, Mar 15, 2013 at 07:34:32PM +0100, Frederic Weisbecker wrote:
2013/3/15 Oleg Nesterov o...@redhat.com:
On 03/15, Frederic Weisbecker wrote:
The lack of the barrier?
I thought about this, this should be fine? atomic_add_unless() has the
same
problem, but this is
On Fri, Mar 15, 2013 at 12:24 AM, Oleg Nesterov wrote:
>> From: Ming Lei
>> Subject: atomic: improve
>> atomic_inc_unless_negative/atomic_dec_unless_positive
>>
>> Generally, both atomic_inc_unless_negative() and
>> atomic_dec_unless_positive() need at least two atomic_cmpxchg() to
>> complete
> From: Ming Lei
> Subject: atomic: improve atomic_inc_unless_negative/atomic_dec_unless_positive
>
> Generally, both atomic_inc_unless_negative() and
> atomic_dec_unless_positive() need at least two atomic_cmpxchg() to
> complete the atomic operation. In fact, the 1st atomic_cmpxchg() is just
>
From: Ming Lei tom.leim...@gmail.com
Subject: atomic: improve atomic_inc_unless_negative/atomic_dec_unless_positive
Generally, both atomic_inc_unless_negative() and
atomic_dec_unless_positive() need at least two atomic_cmpxchg() to
complete the atomic operation. In fact, the 1st
On Fri, Mar 15, 2013 at 12:24 AM, Oleg Nesterov o...@redhat.com wrote:
From: Ming Lei tom.leim...@gmail.com
Subject: atomic: improve
atomic_inc_unless_negative/atomic_dec_unless_positive
Generally, both atomic_inc_unless_negative() and
atomic_dec_unless_positive() need at least two
38 matches
Mail list logo
