<azonenberg>
ARM architecture gurus: anybody familiar with the details of how Cortex-M7 DTCM works with regards to the AHBS bus?
<azonenberg>
in particular, it looks like DTCM can be accessed by three different logical memory channels: two 32-bit DTCM channels from the CPU (allowing dual-issue of load/load, load/store instructions... but its kinda implied you can't store/store dual issue)
<azonenberg>
and then an AHBS bus intended to allow DMA to access the TCMs
<azonenberg>
It looks like the D0TCM and D1TCM buses coming off the CPU are physically separate SRAMs
<azonenberg>
and those buses physically go to the SRAM, so if there's contention where the CPU wants to access an address in TCM at the same time as the AHBS one of them has to wait?
<azonenberg>
(i.e. the TCM SRAM is physically single ported)
<azonenberg>
aha ok so the TCMs are interleaved
<azonenberg>
so even numbered 32-bit words are in D0TCM and odd in D1TCM
agent314 has joined #osdev
goliath has joined #osdev
vdamewood has joined #osdev
X-Scale has quit [Ping timeout: 256 seconds]
bauen1 has quit [Ping timeout: 255 seconds]
GeDaMo has joined #osdev
netbsduser has joined #osdev
JTL has quit [Read error: Connection reset by peer]
zetef has joined #osdev
zetef has quit [Client Quit]
Left_Turn has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 265 seconds]
agent314 has quit [Ping timeout: 260 seconds]
Yoofie647 has joined #osdev
Yoofie64 has quit [Ping timeout: 255 seconds]
Yoofie647 is now known as Yoofie64
memset_ has quit [Ping timeout: 260 seconds]
memset has joined #osdev
agent314 has joined #osdev
spareproject has joined #osdev
bauen1 has joined #osdev
SophiaNya has quit [Remote host closed the connection]
ptrc has quit [Remote host closed the connection]
SophiaNya has joined #osdev
ptrc has joined #osdev
gildasio has quit [Ping timeout: 260 seconds]
gildasio has joined #osdev
FreeFull has quit []
karenthedorf has joined #osdev
karenthedorf has quit [Remote host closed the connection]
<vin>
Okay I have a super basic question: on modern intel CPUs, If data is cached in L3, does accessing it require any address translation (there by a TLB lookup)? IMO it should not and dTLB will only happen when L3 misses and need to go to DRAM to fetch from the physical page
eddof13 has joined #osdev
eddof13 has quit [Quit: eddof13]
osdev199 has joined #osdev
MrBonkers has joined #osdev
frkzoid has quit [Ping timeout: 264 seconds]
osdev199 has quit [Client Quit]
<vin>
because most caches today are physically addressed
<Mutabah>
vin: I _think_ that the L3 is outside of address translation
<Mutabah>
so, the TLB is involved in accessing data in it
<vin>
Wait why? They are physically addressed, so what do we need to translate and lookup from TLB?
<Mutabah>
Well, that's the point - to know what cache slot to look at, you need to translate virtual to physical
agent314 has quit [Remote host closed the connection]
FreeFull has joined #osdev
<vin>
Ahah, so even if you have cached data in L3 (50 cycles to read) but incur a TLB miss (15 cycles) and must do a page walk (50 cycles), you will pay additional 65 cycles. Why not make the caches virtually addressed?
karenthedorf has quit [Ping timeout: 265 seconds]
<Mutabah>
afaik, a TLB miss for data that is still in cache is pretty unlikely
<Mutabah>
well... maybe if the TLB got flushed due to an address space switch
<Mutabah>
but, how would the cache handle that (without using ASIDs)
<zid>
sounds horrible
<zid>
You'd have to flush your l3 between processes for shared memory
<zid>
and the point of l3 is to share memory, more or less
<zid>
(you can't tell if it's the same memory or not by virtual address)
Arthuria has joined #osdev
JTL has joined #osdev
Matt|home has joined #osdev
<Matt|home>
hi.
heat has joined #osdev
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 252 seconds]
Turn_Left has joined #osdev
hwpplayer1 has joined #osdev
Left_Turn has quit [Ping timeout: 248 seconds]
eddof13 has joined #osdev
Arthuria has quit [Ping timeout: 276 seconds]
gcoakes has joined #osdev
josuedhg has joined #osdev
xx0a_q has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
freakazoid332 has joined #osdev
gcoakes has quit [Quit: gcoakes]
gcoakes has joined #osdev
Matt|home has quit [Quit: Client closed]
exit70 has quit [Ping timeout: 272 seconds]
gcoakes has quit [Ping timeout: 265 seconds]
exit70 has joined #osdev
bauen1 has joined #osdev
Matt|home has joined #osdev
FreeFull has quit [Ping timeout: 248 seconds]
memset has quit [Ping timeout: 260 seconds]
eddof13 has quit [Quit: eddof13]
eddof13 has joined #osdev
xenos1984 has quit [Ping timeout: 248 seconds]
xenos1984 has joined #osdev
<heat>
yesterday i tried to write some sort of build system-ish stress test but ended up writing a fork bomb instead
<heat>
great stuff
eddof13 has quit [Quit: eddof13]
eddof13 has joined #osdev
memset has joined #osdev
xx0a_q has quit [Quit: WeeChat 4.3.5]
xenos1984 has quit [Ping timeout: 272 seconds]
eddof13 has quit [Quit: eddof13]
xenos1984 has joined #osdev
eddof13 has joined #osdev
_rink has joined #osdev
MrCryo has quit [Remote host closed the connection]
theyneversleep has joined #osdev
spareproject has quit [Ping timeout: 252 seconds]
<nikolar>
Lel
<nikolar>
Did onyx survive
eddof13 has quit [Quit: eddof13]
eddof13 has joined #osdev
X-Scale has joined #osdev
eddof13 has quit [Read error: Connection reset by peer]
<heat>
i was testing it on linux
<heat>
linux barely survived
<heat>
systemd itself was taking 50% CPU reaping processes, killall, pgrep couldn't kill them all, htop couldn't see the procs popping in and out
X-Scale has quit [Ping timeout: 256 seconds]
<heat>
the only way was rebooting
goliath has quit [Quit: SIGSEGV]
<mjg>
that's definitely not accurate
X-Scale has joined #osdev
<heat>
is it? try to kill a forkbomb boss
<heat>
you could try to nuke the user but i'm not sure if that works
<mjg>
trying to get it sorted by the user which started the problem is indeed troublesome
<mjg>
but root should have reasonable time provided there are sensible limits for your shite user
<mjg>
admittedly there may not be
<mjg>
my lulubuntu says -u: processes 63192
<mjg>
for my unpriv user
<mjg>
which indeed can fuck up the machine real good
X-Scale has quit [Ping timeout: 256 seconds]
<heat>
i didn't fuck up the machine cuz i actually wrote job control
<heat>
so it was actually just cycling job tokens through the pipe through never ending never kill-or-top-catched fork
<mjg>
i'll note tho "stop this fucking user from forking" is not necessarily a bad feature
X-Scale has joined #osdev
<mjg>
alternatively "reliably SIGSTOP all fucking processes by this fucking user"
<mjg>
this kind of a feature is already needed for containers 'n shit
Turn_Left has quit [Read error: Connection reset by peer]
torresjrjr has quit [Read error: Connection reset by peer]
torresjrjr has joined #osdev
Left_Turn has joined #osdev
MiningMarsh has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 244 seconds]
FreeFull has joined #osdev
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<zid>
It's been over 120 days since you opened Cloud Shell from the Google Cloud Platform console. In 7 days, your Cloud Shell home directory will be automatically scheduled for deletion.