Re: ARM WFET application scenario consultation

From: Marc Zyngier <maz@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: yangwendong <yangwendong@huawei.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Martin Weidmann <Martin.Weidmann@arm.com>,
	linux-arm-kernel@lists.infradead.org, wanghaibin.wang@huawei.com,
	Zenghui Yu <yuzenghui@huawei.com>,
	"wangjingyi (D)" <wangjingyi11@huawei.com>
Subject: Re: ARM WFET application scenario consultation
Date: Mon, 12 Apr 2021 14:09:10 +0100	[thread overview]
Message-ID: <878s5nodjd.wl-maz@kernel.org> (raw)
In-Reply-To: <20210412124637.GE2060@arm.com>

On Mon, 12 Apr 2021 13:46:37 +0100,
Catalin Marinas <catalin.marinas@arm.com> wrote:
> 
> On Mon, Apr 12, 2021 at 08:08:23PM +0800, yangwendong wrote:
> > Recently, a new feature of WFE with timeouts has been added to ARMv8.
> > I have some doubts about the application scenarios of this feature.
> > 
> > 1) Arm spec said that WFE or WFET can be used in spinlock. Since the
> > thread using spinlock can't be sleep, if we use the wfet instruction, we
> > can do nothing but wait when timeout,  so what's the difference between
> > the two instructions in this scenario?
> 
> Not much point in using it it in a classic spinlock, unless you have
> some specific implementation that's supposed to time out.
> 
> Note that we already enabled the event stream in Linux so that an event
> is generated at 100KHz waking up any WFE. One reason we had for this was
> some hardware errata where events between clusters were not generated.
> Another was some small delays required in in certain user programs
> without going through a kernel syscall, though not sure anyone's
> actually using it.
> 
> > 2) Are there any other special scenarios where using wfet instructions
> > can be beneficial ?
> 
> In the kernel we could replace our udelay loop with WFIT for example
> (not WFET because of the event stream). As for user, we can expose a
> HWCAP but it's up to user libraries to make use of it.

Note that since c219bc4e9205K ("arm64: Trap WFI executed in
userspace"), we actively prevent WFI from being used in userspace, and
I would expect WFIT to be given the same treatment. It otherwise is a
precise tool for userspace to synchronise against kernel events.

Thanks,

	N,

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel