Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 17 Apr 2022 10:26:22 +0800
From:   Boqun Feng <boqun.feng@gmail.com>
To:     Guo Ren <guoren@kernel.org>
Cc:     Andrea Parri <parri.andrea@gmail.com>,
        Daniel Lustig <dlustig@nvidia.com>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Will Deacon <will@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        linux-arch <linux-arch@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-riscv <linux-riscv@lists.infradead.org>,
        Guo Ren <guoren@linux.alibaba.com>
Subject: Re: [PATCH V2 0/3] riscv: atomic: Optimize AMO instructions usage
Message-ID: <Ylt6zqPgimmKpJzg@tardis>
References: <20220412034957.1481088-1-guoren@kernel.org>
 <YlbwOG46mCR8Q5tJ@tardis>
 <CAJF2gTRws6RqKmJHBdKsycWSkFgYna_MocJ+qp3Z9r1v7mQzsg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="gsEGlVkScL5MXyzb"
Content-Disposition: inline
In-Reply-To: <CAJF2gTRws6RqKmJHBdKsycWSkFgYna_MocJ+qp3Z9r1v7mQzsg@mail.gmail.com>
Precedence: bulk


--gsEGlVkScL5MXyzb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 17, 2022 at 12:49:44AM +0800, Guo Ren wrote:
[...]
>=20
> If both the aq and rl bits are set, the atomic memory operation is
> sequentially consistent and cannot be observed to happen before any
> earlier memory operations or after any later memory operations in the
> same RISC-V hart and to the same address domain.
>                 "0:     lr.w     %[p],  %[c]\n"
>                 "       sub      %[rc], %[p], %[o]\n"
>                 "       bltz     %[rc], 1f\n".
> -               "       sc.w.rl  %[rc], %[rc], %[c]\n"
> +               "       sc.w.aqrl %[rc], %[rc], %[c]\n"
>                 "       bnez     %[rc], 0b\n"
> -               "       fence    rw, rw\n"
>                 "1:\n"
> So .rl + fence rw, rw is over constraints, only using sc.w.aqrl is more p=
roper.
>=20

Can .aqrl order memory accesses before and after it (not against itself,
against each other), i.e. act as a full memory barrier? For example, can
we end up with u =3D=3D 1, v =3D=3D 1, r1 on P0 is 0 and r1 on P1 is 0, for=
 the
following litmus test?

    C lr-sc-aqrl-pair-vs-full-barrier
   =20
    {}
   =20
    P0(int *x, int *y, atomic_t *u)
    {
            int r0;
            int r1;
   =20
            WRITE_ONCE(*x, 1);
            r0 =3D atomic_cmpxchg(u, 0, 1);
            r1 =3D READ_ONCE(*y);
    }
   =20
    P1(int *x, int *y, atomic_t *v)
    {
            int r0;
            int r1;
   =20
            WRITE_ONCE(*y, 1);
            r0 =3D atomic_cmpxchg(v, 0, 1);
            r1 =3D READ_ONCE(*x);
    }
   =20
    exists (u=3D1 /\ v=3D1 /\ 0:r1=3D0 /\ 1:r1=3D0)

Regards,
Boqun

--gsEGlVkScL5MXyzb
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEj5IosQTPz8XU1wRHSXnow7UH+rgFAmJbesoACgkQSXnow7UH
+rie9Af/UTwzwnSrsPDa9Dt5IvnF9QCWblr10PoMYKlA7wHaAC7xRVicoRsmLAXF
zIlFIQEcZdxH3/o7cVOtaFDRaNoY6q667AxcTP+vzwcTBoWIAvSo7kip2ZtTAtbE
8sj/bm+AiMfAet+sJ/I0gQNm3wPC3Q0MH5XcuGTpDZQlGny+/mB5s42Ii8vpt+UJ
fgHdn8TqJ4m+PURvx8Rzumv9Uz6y6X8C4/VgZTNOVA3de1tcGw6kinIvOAML8F+v
mAyg5MBo3DJ2Egh4aE1bzNvcfH97MbUJIAECztxhTKcgd77I16hBhhdtZoHRkZYR
6vmBhnqkQm8683s2qqt2HOUZlmrfJQ==
=Fcy2
-----END PGP SIGNATURE-----

--gsEGlVkScL5MXyzb--