On Wed, 18 Mar 2026 11:51:28 -0400
Mathieu Desnoyers <[email protected]> wrote:
> On 2026-03-18 11:29, Masami Hiramatsu (Google) wrote:
> >>
> >> - AFAIU, you are not trying to evince cache lines after creation
> >> of a new virtual mapping (which is the documented intent of
> >> flush_cache_vmap).
> >
> > Ah, OK. That's a good point!
> > (anyway I will replace it with do { } while (0) in the next version.)
> >
> >>
> >> - AFAIU flush_cache_vmap maps to no-code on arm64 (asm-generic), what am
> >> I missing ? It makes sense to be a no-op because AFAIR arm64 does not
> >> have to deal with virtually aliasing caches.
> >
> > Yeah, so my patch also introduces arm64 specific implementation.
>
> Just make sure to call this something else than "flush_cache_vmap",
> because you don't want to slow down vmap on arm64 which does not
> require to evince and certainly not write back cache lines after
> creation of a new virtual mapping.
OK, I will just leave it an empty do-while in asm-generic instead of
flush_cache_vmap(). If any architecture finds persistent ring buffer
needs to write back caches, it can add its own flush implementation.
BTW, do we need dmb(osh)? This runs dcache_clean_pop() after atomic
operation in ring_buffer_record_off().
ring_buffer_record_off(buffer);
arch_ring_buffer_flush_range(buffer->range_addr_start,
buffer->range_addr_end);
Thank you,
>
> Thanks,
>
> Mathieu
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> https://www.efficios.com
--
Masami Hiramatsu (Google) <[email protected]>
