On Sun, 28 Apr 2024 11:55:10 -0500
John Groves <John@xxxxxxxxxx> wrote:
On 24/04/28 01:47PM, Dongsheng Yang wrote:
在 2024/4/27 星期六 上午 12:14, Gregory Price 写道:
On Fri, Apr 26, 2024 at 10:53:43PM +0800, Dongsheng Yang wrote:
在 2024/4/26 星期五 下午 9:48, Gregory Price 写道:
Just to make things slightly gnarlier, the MESI cache coherency protocol
allows a CPU to speculatively convert a line from exclusive to modified,
meaning it's not clear as of now whether "occasional" clean write-backs
can be avoided. Meaning those read-only mappings may be more important
than one might think. (Clean write-backs basically make it
impossible for software to manage cache coherency.)
My understanding is that clean write backs are an implementation specific
issue that came as a surprise to some CPU arch folk I spoke to, we will
need some path for a host to say if they can ever do that.
Given this definitely effects one CPU vendor, maybe solutions that
rely on this not happening are not suitable for upstream.
Maybe this market will be important enough for that CPU vendor to stop
doing it but if they do it will take a while...
Flushing in general is as CPU architecture problem where each of the
architectures needs to be clear what they do / specify that their
licensees do.
I'm with Dan on encouraging all memory vendors to do hardware coherence!
J
Keep in mind that I don't think anybody has cxl 3 devices or CPUs yet, and
shared memory is not explicitly legal in cxl 2, so there are things a cpu
could do (or not do) in a cxl 2 environment that are not illegal because
they should not be observable in a no-shared-memory environment.
CBD is interesting work, though for some of the reasons above I'm somewhat
skeptical of shared memory as an IPC mechanism.
Regards,
John
.