On Sun, Jan 22, 2023 at 09:51:19PM -0800, David Rientjes wrote: > On Fri, 6 Jan 2023, Viacheslav A.Dubeyko wrote: > > > CC: LSF/MM/BPF mailing list. Sorry, missed the list. > > > > > On Jan 6, 2023, at 11:51 AM, Viacheslav A.Dubeyko <viacheslav.dubeyko@xxxxxxxxxxxxx> wrote: > > > > > > Hello, > > > > > > I believe CXL memory is hot topic now. I believe we have multiple topics > > > for discussion. I personally would like to discuss CXL Fabric Manager > > > and vision of FM architecture implementation. I am going to share the topic > > > in separate email. I would like to suggest a special session for CXL memory > > > related topics. > > > > > > How everybody feels about it? > > > > > I think this makes a lot of sense, thanks for suggesting it. > > Should this be a BoF or just a normal topic proposal? I assume that there > could be several different topics of interest all related to CXL.mem. > +1 for a normal topic proposal. > Specifically interesting would be the division of work between the kernel > and userspace to manage memory placement on systems with locally attached > CXL. And, further, what APIs userspace would have at its disposal for > explicit optimization of this placement that would exist beyond what is > available for NUMA. Given virtual hierarchies can exist I think this becomes a very important topic of discussion. Locally attached CXL is dynamic, and the CXL hierarchy as well as device characteristics are factors in the performance expectations of the host. In addition, I would like to discuss the best way to emulate such topologies. QEMU is a great tool for functional testing, I am not sure if there are ways to leverage it in order to emulate performance characteristics of CXL devices and hierarchies. > > I assume we might also want to chat about CXL 2.0 extensions that would be > useful, especially for cloud providers. > The session about DCDs at Plumbers comes to mind here. In addition, I think this leads into a general discussion of how the dynamic nature of CXL (devices and topologies) will be heavily dependent on hot add and remove of system memory. We have some exploratory work in this area and I am cc'ing the relevant people. > I'd be happy to join in any of the proposals for these topics, just let me > know! +1 for me.
