Comment by zeusk
13 hours ago
why would it? the parent OS can already handle physically contiguous allocations so these should be no different (with the exception that a separate interface can be used to do compute over these buffers/pages).
13 hours ago
why would it? the parent OS can already handle physically contiguous allocations so these should be no different (with the exception that a separate interface can be used to do compute over these buffers/pages).
If it requires physically contiguous RAM to work, then it's not really participating in the full virtual memory system, really. It would be using an exception to it, that can be accommodated to some extent by the OS, but not sitting in demand-paged storage like the rest of the system.
You could still do map-reduce operations, but for it to really fly, what you'd want is a side channel between the memory chips that allows the reduce to happen out of band from the front-side bus and the reduction to be sent to the CPU. And any workflow where you can stream the reduction to the CPU that would be even better for latency.
That really doesn't make sense because your system is already using memory that needs to be physically contiguous but mapped virtually. Also, would you say pinned memory is not part of the virtual memory system??
You're only restricted by the fragmentation of the system memory which is an issue yes, but it's dealt with in other ways.
And the security folks will have tons of fun with this enormously leaky abstraction too.
Hey, just don't store your pagetables in PIM capable sections :)
Linux has been dealing with this kind of thing for over a decade now. Specialized SoCs love their memory carveouts.