Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
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>
In-Reply-To: <a94490f6b1dd43d5985a8b14aa93bd27@AcuMS.aculab.com>
From:   Evan Green <evan@rivosinc.com>
Date:   Thu, 21 Sep 2023 09:44:59 -0700
Message-ID: <CALs-Hsuuhmtg54TRSBtGFR9QGH4LWuO4TxUsg3NVzoPj3g6HzQ@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 3:22=E2=80=AFAM David Laight <David.Laight@aculab.c=
om> 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 other
> > 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
on behalf of all CPUs would come back "unknown", which is true (though
would probably default to the byte-copy version). More specific
environments might choose to curate their scheduling a bit more, and
this info per-core would be useful there.

-Evan