RE: [PATCH -tip 00/12] locking/atomics: Add and use inc,dec calls for FETCH-OP flavors

From: KY Srinivasan
Date: Fri Jun 24 2016 - 14:00:38 EST




> -----Original Message-----
> From: Davidlohr Bueso [mailto:dave@xxxxxxxxxxxx]
> Sent: Friday, June 24, 2016 10:30 AM
> To: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
> Cc: peterz@xxxxxxxxxxxxx; mingo@xxxxxxxxxx; davem@xxxxxxxxxxxxx;
> cw00.choi@xxxxxxxxxxx; dougthompson@xxxxxxxxxxxx; bp@xxxxxxxxx;
> mchehab@xxxxxxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; pfg@xxxxxxx;
> jikos@xxxxxxxxxx; hans.verkuil@xxxxxxxxx; awalls@xxxxxxxxxxxxxxxx;
> dledford@xxxxxxxxxx; sean.hefty@xxxxxxxxx; KY Srinivasan
> <kys@xxxxxxxxxxxxx>; heiko.carstens@xxxxxxxxxx;
> sumit.semwal@xxxxxxxxxx; schwidefsky@xxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH -tip 00/12] locking/atomics: Add and use inc,dec calls for
> FETCH-OP flavors
>
> On Fri, 24 Jun 2016, James Bottomley wrote:
>
> >On Mon, 2016-06-20 at 13:05 -0700, Davidlohr Bueso wrote:
> >> Hi,
> >>
> >> The series is really straightforward and based on Peter's work that
> >> introduces[1] the atomic_fetch_$op machinery. Only patch 1 implements
> >> the actual atomic_fetch_{inc,dec} calls based on
> >> atomic_fetch_{add,sub}.
> >
> >Could I just ask why? atomic_inc_return(x) - 1 seems a reasonable
> >thing to do to me.
>
> For one restoring the old state like that can be racy and looses the notion of
> atomicity. The new family of atomic_fetch_$ops also better express the
How so? Can you expand on the racy part. The subtraction is done on a local copy of
the value.

K. Y

> purpose of the call imo. Finally, the added machinery (considering it came from
> fetch_op() NOHZ needs), was mainly suggested by Linus (although yes, we
> don't have users for all the calls):
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flkml.org%
> 2flkml%2f2016%2f3%2f15%2f352&data=01%7c01%7ckys%40microsoft.com%
> 7c5c7cfad67568440f6e2108d39c5546e0%7c72f988bf86f141af91ab2d7cd011
> db47%7c1&sdata=uZrdmvDCuTp%2bMNHAXzMPT68w%2bVGtvH2V99nUEBr6
> 1ro%3d.
>
> Thanks,
> Davidlohr