LWN: Comments on "Memory-management changes for CXL" https://lwn.net/Articles/931416/ This is a special feed containing comments posted to the individual LWN article titled "Memory-management changes for CXL". en-us Wed, 22 Oct 2025 21:14:30 +0000 Wed, 22 Oct 2025 21:14:30 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Memory-management changes for CXL https://lwn.net/Articles/932663/ https://lwn.net/Articles/932663/ balbir_singh <div class="FormattedComment"> I would encourage Kim to look at <a rel="nofollow" href="https://lwn.net/Articles/713035/">https://lwn.net/Articles/713035/</a> and <a rel="nofollow" href="https://lwn.net/Articles/720380/">https://lwn.net/Articles/720380/</a>. We've tried this in the past, but were held back due to HMM at that time. The idea of using a new MMAP is a bit too open, using madvise() and mempolicy() as alternatives might be better suited.<br> </div> Tue, 23 May 2023 00:50:51 +0000 Memory-management changes for CXL https://lwn.net/Articles/931763/ https://lwn.net/Articles/931763/ joseph.h.garvin <div class="FormattedComment"> I don't understand the point of MMAP_EXMEM if it's just a single bitflag. If there are potentially an arbitrary number of NUMA nodes with wildly different access latency, it doesn't really narrow down where you want to allocate from. Seems like you either need to be able to pass an explicit node ID with every allocation or you need to change the policy right before every allocation to get that effect?<br> <p> When I think about high performance apps I assume they are going to be doing their own management of anticipating what will be hot and cold and determining what tier of memory to use because they will have information the kernel doesn't.<br> </div> Fri, 12 May 2023 15:18:00 +0000