VM madvise semantics

[Thomas Hellström]

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.

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