Hi all, Please see the meeting minutes here: https://github.com/riscv-admin/cache-management-ops/blob/master/minutes/2022-02-28-minutes.md Please feel free to suggest corrections or additions. Also pl

In earlier times, we were not publishing the zoom link in the mailing group or in the meeting invite to keep the meeting to members-only, but I think most groups have given up on that. So I'll update

$ cat ~/Downloads/cmo-zoom-link.txt https://zoom.us/j/2908455492?pwd=LzJRRFNSS0NHUVpocUhuczl6VURxdz09

Use the zoom link inside the zoom.text file attached to the meeting invite. Greg

I tried going to google meet, but no being admited

Sorry for the late notice. I accidentally sent this to the wrong mailing list. We'll meet in about 90 minutes. Cheers, David ---------- Forwarded message --------- From: David Kruckemyer <dkruckemyer@

This is a good discussion, since it's surfacing everyone's assumptions. My understanding of the general request is to apply the software coherent/non-coherent I/O semantics of the current CBOs to a ra

Thanks for clearing that up Greg. I always forget about VA to PA translation, and non-continuous page boundaries, but of course that matters too :) As for affecting all caches in the coherence domain,

Actually there's a key misunderstanding by several people wrt the question David is posing. The current CBO's effectively operate on all the caches in a coherence domain, not just the cache next to th

the same range is likely to be used for several cache ops. writing low & hi to CSRs could be one workaround. this is one problem, and there are several more which i’m probably not aware of yet. the pr

You're describing a range based cacheop, and the problem with those was always how to encode the ranges, In this case, encode ranges and set/way - that's 3 source operands minimum. We could invent a p

That’s one possible implementation. Can Indexed cache ops work conditionally depending upon whether the tag matches a specified <low,high> range? The ones I’ve seen are unconditional — so you are basi

I think you are requesting what were called “Indexed” cache ops in the MIPS ISA. Basically the CMO would take rs1 not as a virtual address, but as an index into the cache (set and way) and operate at

Given this, it seems like a generally applicable/portable method of flushing/cleaning/etc. a large buffer must walk though all the addresses and perform the appropriate global maintenance operation on

David, as we discussed earlier, I strongly support these types of operations, and understand there are controversies. Opening the discussion is a great way to help find a solution that will be "less c

Hi all, Sorry if it wasn't clear from the original email. Certainly, those are interesting topics and solutions to discuss, and I believe they are partially addressed by the NTLH extension. This parti

A hint like "use way#N on a miss" would probably go a long way. Or even "don't use way#N"

we also had talked about hints: e.g. reads from this memory range are read once and/or sequential and thing lien that if apps want to use the cache line fetch but not locality to help implementations

Hi all, In the past, some people have expressed a desire for a more efficient way to manage memory buffers that are much larger than the capacity of one or more caches, up to the capacity of the entir

Hi all, Not much to report on this week, so I'm canceling the meeting again. I do plan to begin soliciting ideas for the so-called "large buffer" problem (starting with a clear definition of what the