[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3156dcdbddc9b1f692bc45adba0893bcc9b58035.camel@amazon.com>
Date: Wed, 6 Nov 2024 17:38:55 +0000
From: "Okanovic, Haris" <harisokn@...zon.com>
To: "catalin.marinas@....com" <catalin.marinas@....com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "rafael@...nel.org"
<rafael@...nel.org>, "sudeep.holla@....com" <sudeep.holla@....com>,
"joao.m.martins@...cle.com" <joao.m.martins@...cle.com>,
"ankur.a.arora@...cle.com" <ankur.a.arora@...cle.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"konrad.wilk@...cle.com" <konrad.wilk@...cle.com>, "wanpengli@...cent.com"
<wanpengli@...cent.com>, "cl@...two.org" <cl@...two.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mingo@...hat.com" <mingo@...hat.com>, "maobibo@...ngson.cn"
<maobibo@...ngson.cn>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>, "misono.tomohiro@...itsu.com"
<misono.tomohiro@...itsu.com>, "daniel.lezcano@...aro.org"
<daniel.lezcano@...aro.org>, "arnd@...db.de" <arnd@...db.de>,
"lenb@...nel.org" <lenb@...nel.org>, "will@...nel.org" <will@...nel.org>,
"hpa@...or.com" <hpa@...or.com>, "peterz@...radead.org"
<peterz@...radead.org>, "boris.ostrovsky@...cle.com"
<boris.ostrovsky@...cle.com>, "vkuznets@...hat.com" <vkuznets@...hat.com>,
"bp@...en8.de" <bp@...en8.de>, "Okanovic, Haris" <harisokn@...zon.com>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "mtosatti@...hat.com"
<mtosatti@...hat.com>, "x86@...nel.org" <x86@...nel.org>,
"mark.rutland@....com" <mark.rutland@....com>
Subject: Re: [PATCH 3/5] arm64: refactor delay() to enable polling for value
On Wed, 2024-11-06 at 09:18 +0000, Catalin Marinas wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Tue, Nov 05, 2024 at 12:30:39PM -0600, Haris Okanovic wrote:
> > + do {
> > + cur = __READ_ONCE_EX(*addr);
> > + if ((cur & mask) == val) {
> > + break;
> > + }
> > wfet(end);
>
> Constructs like this need to be entirely in assembly. The compiler may
> spill 'cur' onto the stack and the write could clear the exclusive
> monitor which makes the wfet return immediately. That's highly CPU
> implementation specific but it's the reason we have functions like
> __cmpwait() in assembly (or whatever else deals with exclusives). IOW,
> we can't have other memory accesses between the LDXR and whatever is
> consuming the exclusive monitor armed state (typically STXR but WFE/WFET
> can be another).
Agreed, will rewrite parts of delay() in asm.
>
> --
> Catalin
Powered by blists - more mailing lists