On Wed, 18 May 2022 at 11:10, Anup Patel <anup@xxxxxxxxxxxxxx> wrote: > > > > > + description: > > > > > + Blocksize in bytes for the Zicbom cache operations. The block > > > > > + size is a property of the core itself and does not necessarily > > > > > + match other software defined cache sizes. > > > > > > > > What about hardware defined cache sizes? I'm scratching my head as to > > > > what a 'software defined cache size' is. > > > > I agree that this should be worded better. The intent was to tell that this > > is different from say the l1-cache-block-size. > > > > I.e. these values can be the same but don't need to be. But I guess I got > > too much lead on by a kernel implementation detail (L1_CACHE_BYTES constant) > > Better to just call it as "the cache block-size expected by Zicbom cache > operations" without getting details of relation with L1 cache block size. I would make this an even stronger statement and assert that Anup's recommended rewording (and staying away from L1 block/line sizes in terminology) is required to accurately reflect the design of the RISC-V CMOs. The Zicbom operation size is in fact decoupled from the l1-cache-block-size (as that would be the cache line size — and therefore the size of fetches/replacements to the cache) as the deliberations within the CMO group showed. This is only the granule that Zicbom instructions operate on (and there might be additional mechanisms at work in the background that ensure that this is safe for any given underlying cache implementation). Cheers, Philipp.