From: Catalin Marinas <catalin.marinas@arm.com>
To: yangwendong <yangwendong@huawei.com>
Cc: 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 13:46:37 +0100 [thread overview]
Message-ID: <20210412124637.GE2060@arm.com> (raw)
In-Reply-To: <26f50e86-dc68-0aca-f29f-19ef2f884c5d@huawei.com>
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.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next parent reply other threads:[~2021-04-12 12:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <26f50e86-dc68-0aca-f29f-19ef2f884c5d@huawei.com>
2021-04-12 12:46 ` Catalin Marinas [this message]
2021-04-12 13:09 ` ARM WFET application scenario consultation Marc Zyngier
2021-04-12 13:15 ` Catalin Marinas
2021-04-12 13:48 ` Marc Zyngier
2021-04-12 14:02 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210412124637.GE2060@arm.com \
--to=catalin.marinas@arm.com \
--cc=Martin.Weidmann@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=wanghaibin.wang@huawei.com \
--cc=wangjingyi11@huawei.com \
--cc=will@kernel.org \
--cc=yangwendong@huawei.com \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).