Hi Jonathan,
On 01/12/2022 11:02, Jonathan Cameron wrote:
On Thu, 20 Oct 2022 16:06:05 +0100 Dan raised an "interesting" point... https://lore.kernel.org/all/6387ed1b67fb7_c957294dd@dwillia2-mobl3.amr.corp....
Dan is arguing that we are obliged to flush all caches on any changing of address decoders. So basically any case where the OS is setting up any CXL memory for access. That applies to hotplug of volatile memory, or any OS managed bring up (including all persistent memory as there isn't currently a good way to bring that up in firmware even if it is there at he beginning).
It's plausible that he is right though I've not thought about it in enough depth yet
- need to talk it through with our architecture experts to make sure I'm not missing something.
If he is, that cache invalidate proposal just became much higher priority.
Great, I've given a gentle nudge to the folk who were looking at this.
If you're looking at a particular platform for this sort of thing, it would be interesting to know what kind of ballpark the latencies are in for the maintenance. I'm in two minds as to whether something about the latency needs advertising, or we need to make it interruptible/restartable. Over a certain amount we need to tell RCU to calm down, even longer I'd start to worry about interrupt latency.
I don't completely follow the CXL discussion. Is it possible this needs doing for a subset of a window? For the NVDIMM use-cases the granularity was implicitly the device. The constraints on firmware may be different if a cache only needs partially invalidating.
Thanks,
James