VM madvise semantics

[Matthew Brost]

On Wed, Jun 04, 2025 at 02:57:50PM +0200, Thomas Hellström wrote:
> Hi!
> 
> I'm starting an email thread to move forward the questions Himal had on
> the madvise semantics:
> 
> 1) Whether to support an array of ops? 
> 
> IMO the VM_BIND implementation got very complicated due to this and the
> needed rollback support. Perhaps due to single op splitting turning to
> multiple ops it would've been hard to avoid that. Can we avoid
> supporting an array of ops for madvise? If so I'd vote for single op.
> 

I don't think rollback is strickly required as madvise failing mid-array
is not fatal compared to a VM bind failing mid-array not rolling back
is. At worst some VMAs/ranges/BOs might have had their attributes
changed and may have not. That said, not opposed to for single op if
that is what you prefer.

> 2) Purgeability. If it's not implemented yet we shouldn't merge an uapi
> for it, but ensure that it would at least be possible moving forward. 
> 

I agree, I think I mentioned that in my reviews too - pull this out of
the uAPI before the final merge.

> 3) Multi-device. In the spirit of the above I guess it makes sense if
> UMD wants to select between VRAM and SRAM now to merge an interface
> that supports *only* that. When we add multi-device support we could
> perhaps add another op, or an extension to support agreed multi-device
> semantics. Even if this means rolling back to Himal's original
> suggestion of a preferred placement UAPI.
> 

I think the way Himal as this coded works for both multi-device and
choose between SRAM / VRAM. 

The devmem_fd field means:

-1 == SRAM
0 == VRAM
0 > Multi-device devmem FD handle (NIY)

I think this is a solid enough interface we are good? Am I missing
something?

Matt

> Thoughts?
> 
> Thomas
>