marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
<sven>
nice! i was planning to add sprr/gxf registers to regs.json but i like the separate file for apple-regs :)
<pipcet[m]>
marcan: the AIC driver currently sends all irq interrupts to CPU0, right?
<marcan>
pipcet[m]: no, it supports SMP
<pipcet[m]>
marcan: thanks, I'll have a look to see why it's not working here :-)
<pipcet[m]>
probably my own fault
crabbedhaloablut has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #asahi
zorg24 has joined #asahi
flokk[m] has joined #asahi
herbas has joined #asahi
maknho___ has quit [Ping timeout: 252 seconds]
herbas has quit [Client Quit]
<maz>
pipcet[m]: the default affinity is to CPU0. you can play with /proc/irq/*/smp_affinity* to set it to any random CPU.
maknho___ has joined #asahi
easylee has joined #asahi
WCat[m] has joined #asahi
AWanderer has joined #asahi
maknho____ has joined #asahi
maknho___ has quit [Ping timeout: 260 seconds]
maknho____ has quit [Quit: WeeChat 2.3]
maknho has joined #asahi
agnem has quit [Quit: WeeChat 3.0.1]
agnem has joined #asahi
raster has joined #asahi
tomtastic has quit [Ping timeout: 240 seconds]
tomtastic has joined #asahi
sven_ has joined #asahi
sven has quit [Ping timeout: 248 seconds]
sven_ is now known as sven
<pipcet[m]>
but just one at a time, right?
JTL has quit [Ping timeout: 252 seconds]
JTL has joined #asahi
<marcan>
pipcet[m]: the config lets you specify an arbitrary CPU set, but I think Linux will then pick one from that or so
<marcan>
AIC lets you set multiple bits, but I think the hardware always goes to the first CPU? I need to try again and see exactly what happens
<marcan>
the driver currently only sets one bit
<pipcet[m]>
I think the not-to-be-mentioned old driver set several bits and there appeared to be some degree of IRQ balancing going on with it...
<pipcet[m]>
but overall I'm glad I don't have to use that anymore, the existing device drivers work fine with the new aic driver, with a few modifications :-)
<pipcet[m]>
I understand it's probably not worth it to make the change, but I do wonder why we have all the FIQ code in the AIC driver even though they appear to be totally independent. The one dependency is that we can use FIQ or IRQ IPIs, but not both, right?
<marcan>
pipcet[m]: precisely because of that: because once that's implemented, we have to pick one, and two drivers would have to coordinate that
<marcan>
but also, things started with a common irq/fiq vector and only got split later
<marcan>
it's kind of a wash which way to do it, but if we end up with better reasons to have them merged in the future, doing so post-facto would be a lot more painful
<marcan>
so, even though it might be uglier, it seems safer to do it this way
<marcan>
and yeah, if hardware IRQ balancing works as intended we should certainly supported; I actually had that at some point but decided to play it safe for now
TheJollyRoger has quit [Ping timeout: 240 seconds]
<marcan>
but for what it's worth, setting multiple bits in smp_affinity on my x86 iMac also ends up with everything on one CPU so... :-)
<pipcet[m]>
but with the x86 there's no real difference between the cores, is there :-)
TheJollyRoger has joined #asahi
<pipcet[m]>
but really, those are very minor issues. The driver appears to work, though I did hack in a few things to get the other device drivers working and need to investigate more.
<pipcet[m]>
(using it with the Corellium drivers, for the time being)
<maz>
in general, dispatching on multiple CPUs has an adverse effect on the interrupt service latency.
<maz>
that's at least what the x86 and GICv2 experience has taught us over the years.
<maz>
things may be different on M1, but a change would need to be backed by hard numbers.
<kettenis1>
which is kinda hard to do without more device drivers ;)
<maz>
problem solved! :D
zorg24 has quit [Quit: Connection closed]
<pipcet[m]>
turns out disabling your keyboard interrupt still isn't a good idea!
<maz>
it's called secure computing.
choozy has joined #asahi
<pipcet[m]>
I do wonder how the AIC selects which CPU to send the interrupt to. It appears to be mostly the first two ones to have their bits set, but once in a while it's the third.
<pipcet[m]>
so probably the first CPU to be considered "idle", by whatever standard?
<opticron>
that standard is probably "interrupts enabled"
<maz>
that'd mean the interrupt controller can peek into PSTATE for each CPU. doesn't scale to big systems, but certainly a good optimisation on a small system.
<pipcet[m]>
IRQs are enabled separately from FIQs, right?
<opticron>
does the AIC actually select a CPU or does it deliver the interrupt to all affinity-selected CPUs and then the one that gets there first sees a real interrupt while the others see a "spurious" interrupt if they catch it at the same time?
<maz>
yup. different bit in PSTATE.
<maz>
opticron: I'm sure it is extensively documented in the spec.
<opticron>
lol
<opticron>
heck, I'm not even sure AIC *HAS* spurious interrupts like GICv2 and GICv3
<pipcet[m]>
opticron: good point, we should print out a message for spurious interrupts
<opticron>
also lol
<pipcet[m]>
so we could run userspace code with IRQs disabled, if we were using FIQ IPIs?
<maz>
err... no.
<pipcet[m]>
on all but one core, at least :-)
<maz>
I guess you could use CPU isolation which comes very close to that.
<pipcet[m]>
just thinking about possibilities here. it'd be silly to ruin a CPU's cache if another CPU is idle
tomtastic has quit [Ping timeout: 246 seconds]
modrobert has quit [Read error: Connection reset by peer]
TheJollyRoger has quit [Ping timeout: 240 seconds]
tomtastic has joined #asahi
<pipcet[m]>
and what's wrong with running userspace code without enabling IRQs on 7 cores?
<maz>
pipcet[m]: that's fine as a special case, and you can do that from userspace by moving all the IRQs to a single core. But in general, you want to be able to place interrupts where they matter most, specially if you have to deal with devices doing back-to-back interrupts (wild guess, a router).
<pipcet[m]>
okay, thought there was a more serious issue. You're right that it's best done in userspace, though.
modrobert has joined #asahi
<maz>
as I mentioned earlier, CPU isolation does exactly that to avoid any disruption to userspace performing a timing-critical task. if you're careful enough, you don't even get IPIs. of course, that comes at the expense of moving all ancillary tasks to worker CPUs which have to deal with everything the kernel normally does in the background.
<pipcet[m]>
I think you're right for real RT tasks, but I'm just thinking about a performance hack to keep the video player from being interrupted by interrupts (which we will need until we've got the hardware scaler up and running). but, again, just trying to wrap my head around this IRQ-vs-FIQ thing
jeffmiw_ has joined #asahi
jeffmiw_ has quit [Ping timeout: 260 seconds]
maor26 has joined #asahi
TheJollyRoger has joined #asahi
maor26 has quit [Client Quit]
AWanderer has quit [Ping timeout: 240 seconds]
<marcan>
nobody cares about video players, those things have a whole 16-33ms or so to get their work done
<marcan>
now if we're talking low-latency audio, yeah, that's when starting to think about these things *might* matter
<marcan>
it's on my longer-term todo list :-)
<marcan>
(I'm probably going to be moving to linux on M1 for all my live audio stuff)
<kettenis1>
is the audio based on I2S? Wonder how much powerpc heritage there is of that's the case