[AaronFriel]

Ideally then one should be able to use spare VRAM as a second level RAM - an area to page out things to before disk.

I've played a bit with the different memory compression tools on Linux, zram, zswap, and zcache, and they all behave in interesting ways on workloads whose active set is well over 2x available RAM. I played with compiling the Glasgow Haskell Compiler on small and extra small instances of cloud services, I wager this would work for the GPU instances on EC2 to increase their capacity a little.

The transcendental memory model in Linux is interesting for exploring these ideas, and it's one of the things I really like about the kernel. However the last time I played with it (Kernel version ~3.10) I had some lockup issues where the kernel would take up almost all of the CPU cycles with zswap. That was kind of a nasty issue.

[SXX]

> Ideally then one should be able to use spare VRAM as a second level RAM - an area to page out things to before disk.

It's already possible on Linux. You can use SWAP file instead of partition and there also SWAP priorities available.

[AaronFriel]

I've found that putting swap files on things that don't behave like filesystems can cause interesting behaviors. In this case, all writes to the file would go through the VFS. I imagine there could be some curious issues if that write path has any allocations or significant amount of mutation in it.

I would trust more something that got rid of the VFS layer and simply allowed VRAM to be used directly as a second level below RAM using the transcendental memory model.

[wtallis]

And even some otherwise fairly ordinary filesystems don't support swap files (e.g. btrfs).