10:28 <milkylainen> hmm. l2x0 primecell compatible question. I notived that a board was setting (forced) write-through mode for the auorora cache controller in a mvebu cortex-a9 mp. Looked funny to me. Don't know why. So I figured I would fix it and measure any differences. But I can't measure any differences in writespeed when hitting L2. They're about the same as DRAM. Which would indicate wt-mode still active. But

10:28 <milkylainen> not according to the registers. Hints anyone?

10:30 <milkylainen> Actually, none of the settings seem to do any difference in performance, forced wt or wb, or as per pagesettings.

11:27 <arnd> ardb: looking at https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/commit/?h=linux-6.12.y-rt-rebase&id=79f0677c044aa5f5e07fd3ea50b95bc1a02782cc, do you know why we use stop_machine() in arm32 arch_jump_label_transform() but not in arm64?

11:28 <ardb> arnd: i suspect it has to do with less guidance from the architecture as to what kind of code patching is safe under SMP

11:28 <ardb> mrutland: would know

11:29 <ardb> arm64 permits nop to jump/call patching and vice versa without elaborate management of I-caches etc but everything else is potentially unsafe

11:31 <arnd> ok, so I can see how this would break on thumb2 kernels with 32-bit instructions that span two cache lines

15:21 <mrutland> ardb: ardb: yep, on arm64 we know we're doing CMODx-safe B<->NOP patching, and can do that without stop_machine() (but need an IPI to sync things). I don't know whether we can arrange thigns to do the same safely on 32-bit arm

16:04 <ardb> arnd: mrutland i suppose we might get away with doing the same on arm32 but i'm not sure it's worth the hassle