Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
MIME-Version: 1.0
References: <20230920193801.3035093-1-evan@rivosinc.com> <20230920-98a392b40f88c69e852e2c88@fedora>
 <CAOnJCUK7KTO0n_8wDYDxh2ULtEvMWF-re2dEX6nng_tX1AGgPw@mail.gmail.com>
 <CALs-HsuurXBZ2p=jYKvPq6ZMScugm5rBchttD6Wv9Mtupfx3NQ@mail.gmail.com>
 <CAOnJCU+YNOzw39JMjWmJFHY5QjcRrKEwULo+d9WhPfv7TejpbQ@mail.gmail.com>
 <CALs-HsvvnMFErCtShB-30xO8LR4M03riYomZy3FnvEghRua_3g@mail.gmail.com>
 <a94490f6b1dd43d5985a8b14aa93bd27@AcuMS.aculab.com> <CALs-Hsuuhmtg54TRSBtGFR9QGH4LWuO4TxUsg3NVzoPj3g6HzQ@mail.gmail.com>
In-Reply-To: <CALs-Hsuuhmtg54TRSBtGFR9QGH4LWuO4TxUsg3NVzoPj3g6HzQ@mail.gmail.com>
From:   Evan Green <evan@rivosinc.com>
Date:   Thu, 21 Sep 2023 09:49:02 -0700
Message-ID: <CALs-HsuyJ41ohF3sodr5weASWLq2kCHf44Ks_bH=J0gcxKm-Ow@mail.gmail.com>
Subject: Re: [PATCH v2] RISC-V: Probe misaligned access speed in parallel
To:     David Laight <David.Laight@aculab.com>
Cc:     Atish Patra <atishp@atishpatra.org>,
        Conor Dooley <conor@kernel.org>,
        Anup Patel <apatel@ventanamicro.com>,
        Albert Ou <aou@eecs.berkeley.edu>,
        Heiko Stuebner <heiko@sntech.de>,
        Marc Zyngier <maz@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Palmer Dabbelt <palmer@rivosinc.com>,
        Conor Dooley <conor.dooley@microchip.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Jisheng Zhang <jszhang@kernel.org>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Greentime Hu <greentime.hu@sifive.com>,
        "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>,
        Andrew Jones <ajones@ventanamicro.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Sep 21, 2023 at 9:44=E2=80=AFAM Evan Green <evan@rivosinc.com> wrot=
e:
>
> On Thu, Sep 21, 2023 at 3:22=E2=80=AFAM David Laight <David.Laight@aculab=
.com> wrote:
> >
> > ...
> > > > For probing alignment speed, you just care about running it on that
> > > > cpu. Correct ?
> > >
> > > For this we care both about not migrating to other CPUs, and also
> > > secondarily minimizing disturbances while the test is being run.
> > > Usually I equate pre-emption with migration, but in this case I think
> > > the worker threads are bound to that CPU. So I'll keep the
> > > preempt_disable/enable where it is, since it's harmless for CPUs othe=
r
> > > than 0, but useful for 0. I also like it for readability as it
> > > highlights the critical section (as a reader, "is preemption disabled=
"
> > > would be one of my first questions when studying this).
> >
> > You need to disable pre-emption to get any kind of meaningful answer.
> >
> > But why do you need to run the test on more than the boot cpu?
> > If you've a heterogenous mix of cpu any code that looks at the answer
> > is going to behave incorrectly unless it has also disabled pre-emption
> > or is bound to a cpu.
>
> I don't think it's safe to assume misaligned access speed is the same
> across all cores. In a big.little combination I can easily imagine the
> big cores having fast misaligned access and the slow cores not having
> it (though hopefully the slow cores don't kick it to firmware). Since
> this info is presented to usermode per-cpu, I'd like it to be correct.
>
> >
> > One obvious use of the result is to setup some static branches.
> > But that assumes all cpu are the same.
>
> Right, this could be used to set up static branches, or in an ifunc
> selector. This is why we provide pre-computed answers for "all CPUs"
> in hwprobe. If the situation I describe above did happen, code asking

Correction: Not exactly precomputed answers, but cached vDSO data
capable of quickly answering usermode queries for systems with
homogeneous CPUs.