ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
LeSpocky has quit [Ping timeout: 248 seconds]
LeSpocky has joined #armlinux
amitk_ has quit [Ping timeout: 252 seconds]
iivanov has joined #armlinux
iivanov has quit [Ping timeout: 252 seconds]
jclsn has quit [Ping timeout: 265 seconds]
iivanov has joined #armlinux
jclsn has joined #armlinux
heat has quit [Read error: Connection reset by peer]
iivanov has quit [Ping timeout: 246 seconds]
heat has joined #armlinux
spew has quit [Quit: spew]
heat has quit [Ping timeout: 252 seconds]
ellyq__ has quit [Ping timeout: 244 seconds]
ellyq has joined #armlinux
iivanov has joined #armlinux
iivanov has quit [Ping timeout: 252 seconds]
iivanov has joined #armlinux
iivanov has quit [Ping timeout: 252 seconds]
<wens>
today I heard that in Rust, userspace spinlock spin is implemented with "ISB SY" on arm64, as opposed to using "YIELD"
<wens>
IIUC this is not the intended use, but the pipeline stall means a bit more (consistent) latency under lower power vs no-op?
ellyq has quit []
ellyq has joined #armlinux
iivanov has joined #armlinux
iivanov has quit [Ping timeout: 276 seconds]
mvaittin has joined #armlinux
iivanov has joined #armlinux
iivanov has quit [Ping timeout: 252 seconds]
amitk has joined #armlinux
iivanov has joined #armlinux
iivanov has quit [Read error: No route to host]
iivanov has joined #armlinux
iivanov has quit [Ping timeout: 272 seconds]
monstr has joined #armlinux
monstr has quit [Read error: Connection reset by peer]
nsaenz_ has joined #armlinux
monstr has joined #armlinux
nsaenz has quit [Ping timeout: 248 seconds]
nsaenz_ has quit [Ping timeout: 244 seconds]
iivanov has joined #armlinux
iivanov_ has joined #armlinux
iivanov has quit [Read error: Connection reset by peer]
apritzel has joined #armlinux
gclement has joined #armlinux
apritzel has quit [Ping timeout: 252 seconds]
mvaittin has quit [Ping timeout: 252 seconds]
mvaittin has joined #armlinux
cbeznea has joined #armlinux
frieder has joined #armlinux
nsaenz has joined #armlinux
iivanov_ has quit [Remote host closed the connection]
headless has joined #armlinux
iivanov has joined #armlinux
iivanov has quit [Ping timeout: 264 seconds]
sszy has joined #armlinux
apritzel has joined #armlinux
ellyq_ has quit [Ping timeout: 252 seconds]
ellyq_ has joined #armlinux
iivanov has joined #armlinux
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
<maz>
wens: yield doesn't do much, in general. I would have expected a WFE instead, as ISB doesn't do much when it comes to data synchronisation (which is what a spinlock is about).
<maz>
(and I assume this ISB is on the retry path).
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
<abelvesa_>
arnd: fair enough, though I don't see how that is supposed to work if the downstream dtb adds support for new HW that uses a new clock ID which is not in the upstream bindings.
<arnd>
abelvesa_: they can't: downstream dtbs can only rely on bindings that have already been upstreamed, if they tried to use something that is not upstream it won't work if they run an upstream kernel
<abelvesa_>
arnd: so maybe I missunderstood your earlier statement then
<arnd>
adding a clk ID is no different from adding a driver binding here
<abelvesa_>
arnd: exactly
<abelvesa_>
arnd: so "vendor-provided dtb that are expected to just work with upstream kernels and not get upstreamed" is not true in case of new bindings for downstream dtb
headless has quit [Quit: Konversation terminated!]
<arnd>
abelvesa_: I don't understand what you mean. All I'm saying is that anyting that worked with existing dtb on an old kernel should keep working with a new kernel
<arnd>
new bindings are for added features, so they are not expected to appear if the bindings were not used in that dtb
<abelvesa_>
right. I do agree then. My point was that vendor-provided dtbs most of the times might use bindings (such as clock IDs) that are not upstream, and that expected to not work.
<arnd>
abelvesa_: that is also true, but those are not the ones I'm worried about. If a device ships with a non-upstream kernel and custom drivers, we have no obligation to provide drivers in an upstream kernel
<javierm_>
abelvesa_: AFAICT the only supported case for downstream DTBs is if are using only drivers and bindings that are upstream
<javierm_>
using a downstream clock ID would be similar to using a downstream compatible string as arnd said, and it could be that later mainline adds a driver using the same compatible string
<abelvesa_>
javierm_: yes, that's exactly what I was also trying to say about downstream dtbs with upstream kernel
iivanov_ has joined #armlinux
iivanov has quit [Read error: Connection reset by peer]
OLGA39 has joined #armlinux
OLGA39 has quit [Client Quit]
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
<geertu>
abelvesa_: javierm_: arnd: Sometimes the downstream and upstream clock IDs differ
<wens>
the user can take that, atomics and whatever barriers, and put together a spinlock
<HdkR>
Oh, that's really interesting results in that commit message
<maz>
wens: looks odd. I guess it really depends how their spinlock is constructed, but they also attribute properties to ISB that it doesn't guarantee.
<maz>
ISB is *not* a substitute for x86's pause -- that'd be something more similar to WFE, but without the event on exclusive monitor clear.
<javierm_>
geertu: yeah, I know but what I tried to say is that if a downstream DTB has a downstream clock ID that differs from an upstream clock ID, then upstream won't be able to support that DTB
<HdkR>
clrex+wfe for roughly equivalent pause behaviour, since that would mean wfe doesn't respond to any incoming exclusive monitor ownership?
<javierm_>
geertu: that is, the downstream DTB will have to be updated with a newer kernel version. That old DTB should work with newer kernel versions rule only apply for upstream drivers and bindings IMO
<wens>
maz: I assume what they perceive to be a pause and lower power is the pipeline flush and stall?
<maz>
HdkR: maybe. I'm far from being an x86 expert!
<maz>
wens: low power? it forces the CPU to discard anything that's already fetched and decoded, so you obviously end-up with lighting-up the icache again. if anything, ISB causes *more* power usage.
<wens>
lol
<HdkR>
Sadly I'm not sure what or if any events can interrupt x86 pause either. Some hardware can configure it to different delay lengths in cycles even
<maz>
wens: this go ticket shows how people are cargo-culting bizarre constructs without understanding what they are doing. doesn't help that the architecture is pretty crap by not giving a valuable semantic to yield outside of SMT implementations.
monstr has quit [Remote host closed the connection]
iivanov_ has quit []
Saalim has quit [Ping timeout: 264 seconds]
Saalim has joined #armlinux
mvaittin has quit [Ping timeout: 265 seconds]
monstr has joined #armlinux
heat has joined #armlinux
monstr has quit [Ping timeout: 252 seconds]
headless has joined #armlinux
rockosov has joined #armlinux
<robmur01>
wens: usual question is to go one step back and ask why do people want to replicate PAUSE - spin loops are usually waiting for something, and the typical "wait for an update" idiom in AArch64 is LDREX/WFE
<robmur01>
the fact that x86 apparently can't do MWAIT in userspace should not constrain an AArch64 implementation to being illogical
<heat>
x86 can do umwait in userspace
<HdkR>
also waitx for the other vendor
mvaittin has joined #armlinux
<robmur01>
ah, OK, so less "can't use" than "doesn't want to rely on availability of"
<HdkR>
It's sadly quite new on that hardware, so it hasn't made a huge impact yet
<heat>
iirc last i heard mwait is quite expensive and not suited as a pause replacement, which is why e.g spinlocks still use pause
<arnd>
maz, ardb: I'm getting randconfig failures "aarch64-linux-ld: HYP init code too big" on today's linux-next, any idea what may have changed?
<maz>
yeah, there's a patch on the list. gimme a sec
<maz>
arnd: 86msjc56mi.wl-maz@kernel.org
<HdkR>
heat: In microbenching that I've done, spinloop versus umwait response latency went from a minimum of ~450 cycles to ~1000 cycles. waitx is worse at ~200cycles up to ~1500 cycles
<HdkR>
Still not absolutely terrible, but measurably slower
<arnd>
thanks maz
headless has quit [Quit: Konversation terminated!]
<maz>
arnd: I'll try and get Paolo to pick it up shortly.
<robmur01>
also the misconception of ISB somehow being "low power" because of how long it takes to cancel and restart from scratch a load of work already done, is somewhat hilarious :)
mvaittin has quit [Ping timeout: 260 seconds]
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
<maz>
robmur01: I sense a t-shirt coming.
iivanov has joined #armlinux
headless has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
gclement has quit [Ping timeout: 265 seconds]
frieder has quit [Remote host closed the connection]
spew has joined #armlinux
headless has quit [Ping timeout: 265 seconds]
headless has joined #armlinux
fvincenz1 has joined #armlinux
headless has quit [Quit: Konversation terminated!]
Saalim has quit [Read error: Connection reset by peer]
Saalim has joined #armlinux
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #armlinux
fvincenz1 has quit [Read error: Connection reset by peer]
fvincenz1 has joined #armlinux
fvincenz1 has quit [Remote host closed the connection]