VM madvise semantics

[Simona Vetter]

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.

Just seen this fly by and wondering why you even want rollback support?

Looking at core mm and the various m* syscalls that manipulate vma, they
just bail out if things fail halfway through. Or at least don't make any
guarantees, userspace gets to keep the pieces.

And I think that's the semantics we want, because making global promises
around rollback means we need atomicity, which means fine-grained locking
is out. And that doesn't sound like the right way to design this stuff to
me?

Or is there some userspace requirement that wants rollback for some
strange reason?

Cheers, Sima

> 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. 
> 
> 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.
> 
> Thoughts?
> 
> Thomas
> 

-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch