On Fri, Sep 04, 2026 at 09:05:39AM +0800, Qiqi Li wrote: > On 8/17/2026 8:49 AM, Gregory Price wrote: > > It would need to be reserved, and you could use numa emulation but > > that's clunky. I have an RFC for exactly this issue - though i haven't > > pushed it further yet. > > > > https://lore.kernel.org/all/[email protected]/ > > Hi Gregory, > > Sorry for the late reply. > > I took a look at the exclusive-node RFC. The approach looks useful for > device-backed private memory without a firmware-described NUMA node. > Thanks for the pointer. > > We are currently looking into the private-node and CRAM design as a > whole. I noticed that CRAM was not included with the v5 series, and saw > that others were also interested in a v5 version. > > If you already have a CRAM branch or patches based on v5, even if they > are still work in progress, would you mind sharing them? It would be > very helpful for us to continue testing the overall design. >
I dropped it off because it was starting to become unwieldly, but i am continuing to maintain a branch on my github: https://github.com/gourryinverse/linux/commits/scratch/gourry/cramtest/cram_72/ I have not posted a new version in some time and it has been reworked significantly in the past few months - but I plan to talk about this particular branch and the tests I've run with it at the device memory LPC micro-conference. I validated this branch against most in-tree (relevant) filesystems for the page-cache extension, but I imagine the anon-only version subset is the more immediately interesting for upstream development. I may include the anon-only version in v6, but I've been a bit busy shoring up the base private memory node core and implementing kernel selftests and LTP tests to ensure there's no userland api regressions. I hope to get something out later this month. ~Gregory
