09:46 <cmarinas> arnd: PG_dcache_clean is misnamed. I think rmk replied on one of the threads that for modern CPUs we use it to synchronise the I and D caches. So even if a device would be coherent, we still need to handle this. But AFAICT it's the responsibility of the driver/VFS to call flush_dcache_page() if a page was modified.

09:49 <arnd> cmarinas: from what I can tell, file systems call flush_dcache_page() only when they modify (from the CPU) data in a page that may get mapped into userspace, not when it gets paged in from a block device

09:51 <arnd> it looks like both armv7 (with non-aliasing dcache) and armv8 do the same thing with icache here, and roughly the same as a lot of the other architectures, while the dcache aliasing is the exception

09:54 <arnd> setting the PG_dcache_clean after a noncoherent DMA is probably something that should not really be done differently between arm32 and arm64, i.e. one of the two options is likely better than the other regardless of wordsize, but it's possible that the measurable performance impact as robmur01 said is minimal

09:57 <arnd> when I looked through the architectures figuring out the other differences, I noticed that some older mips cores turn a page-sized (or larger) dcache flush into "flush all caches because that's faster", and saving that probably makes a huge difference

10:05 <cmarinas> arnd: with non-coherent DMA, we could in theory avoid the D-cache maintenance but we still need the I-cache invalidation. The __sync_icache_dcache() function on arm64 uses the PG_dcache_clean bit to decide whether to do any such maintenance. So we shouldn't really set PG_dcache_clean via arch_dma_mark_clean() unless we add another bit called PG_icache_clean or something.

10:06 <arnd> cmarinas: I thought the icache has to be cleaned in both cases here, regardless of whether PG_dcache_clean is set by a file system or by DMA

10:07 <arnd> nice, I just noticed we can kill off cache_ops_need_broadcast() once armv6 smp support is gone

10:19 <cmarinas> arnd: looking through the code, arm32 does indeed always invalidates the I-cache irrespective of the PG_dcache_clean bit. On arm64, however, we only clean the I-cache if !PG_dcache_clean

10:24 <cmarinas> not sure how we ended up with this difference between arm32 and arm64 but I don't see why we should always invalidate the I-cache every time we set an executable user PTE.

10:26 <cmarinas> it's even worse on arm32 as it does a __flush_icache_all() that is broadcast (ARMv7) to all the CPUs.

13:10 <arnd> cmarinas: I tried to dig a little deeper into the history, but in the end it's all your code and you'd probably know best. The unconditional __flush_icache_all() in __sync_icache_dcache() is from 6012191aa9c6 ("ARM: 6380/1: Introduce __sync_icache_dcache() for VIPT caches")

13:11 <arnd> you mention there that this is similar to ia64 and powerpc, but both at the time did the dcache+icache flush conditionally, just like arm64 has always done

13:11 <arnd> instead, the logic seems to come from your earlier 826cbdaff297 ("[ARM] 5092/1: Fix the I-cache invalidation on ARMv6 and later CPUs")

13:15 <arnd> At the time, the PG_arch_1 bit was still called PG_dcache_dirty, so it's possible the logic didn't keep track of the state enough to safely skip the flush_icache_all

13:17 <cmarinas> arnd: I don't fully remember the reasoning at the time. You are right, we had the changed polarity at the time and it turned out that a lot of paths were not setting the PG_arch_1 bit. With non-coherent DMA, the D-cache was alright and we were missing the I-cache, hence always doing it.

13:18 <cmarinas> the code evolved but without the optimisation for the I-cache invalidation.

13:19 <cmarinas> I don't remember whether ARMv7 had this "asid-tagged vivt I-cache" (it was eventually dropped in ARMv8). Since the I-cache was VIVT, it always needed an invalidation every time it was mapped.

13:20 <cmarinas> so yeah, as a cover all all combinations, the arm32 code is correct. But it could be optimised for ARMv7 SMP a bit by only invalidating the I-cache if the PG_dcache_clean is cleared.

13:35 <arnd> cmarinas: I suppose the arm32 __sync_icache_dcache() could also use DCCMVAU instead of DCCIMVAC, as in 0a28714c53fd ("arm64: Use PoU cache instr for I/D coherency"), right?

13:40 <marc|gonzalez> Hello everyone, trying to use perf to print a full system capture & group cycles by "command" (processes, IRQ handlers, kworkers)

13:41 <marc|gonzalez> Haven't found the magical command-line option or perf script to do that. Was starting to write something custom, feels wrong.

13:42 <marc|gonzalez> I put the kernel in performance governor (to disable DVFS) and nohlt (to keep counting cycles even in idle)

13:44 <marc|gonzalez> also how do I get perf to print event counts, not percentages, for each symbol hit

13:46 <robmur01> `perf report -n ...`, I think

13:46 <marc|gonzalez> wow no idea how I missed that... thanks robmur01

13:52 <marc|gonzalez> is there also a flag to add the pid?

13:53 <marc|gonzalez> I see one may sort by pid, but I want to show the pid. And --tasks seems to present the data completely differently (though might be what I'm looking for)

13:55 <marc|gonzalez> -s pid seems to do exactly what I was looking for :)

13:56 <marc|gonzalez> perf report -s pid -n | head -40

14:09 <cmarinas> arnd: right, PoU is sufficient.

21:32 <Endermen1094> Question how different is it in day to day use going from x86_64 chromebook to arm64 laptop (thinking about pinebook pro )?

21:34 <Endermen1094> Like what are some hertels I can expect

21:35 <Endermen1094> And would source based distros be a better option then binary distros for software availability

21:38 <Endermen1094> And also why dues it seem to have more scripts to set things up then nonstandard chromebooks (iirc 2+ for installing it and audio scripts

21:44 <Endermen1094> Like what bag of worms am I getting into