Driver-driven paging?

Hi!

While trying to put together an improved graphics memory manager in the DRM kernel module, I've identified a need to swap out backing store pages which haven't been in use for a while, and I was wondering if there is a kernel mm API to do that?

Basically when a graphics object is created, space is allocated either in on-card video RAM or in a backup object in system RAM. That backup object can optionally be flipped into the AGP aperture for fast and linear graphics card access.

What I want to do is to be able to release backup object pages while maintaining the contents. Basically hand them over to the swapping system and get a handle back that can be used for later retrieval. The driver will unmap all mappings referencing the page before handing it over to the swapping system.

Is there an API for this and is there any chance of getting it exported?

Quoted 9 lines · Thomas Hellstrom

Hi!

While trying to put together an improved graphics memory manager in the DRM kernel module, I've identified a need to swap out backing store pages which haven't been in use for a while, and I was wondering if there is a kernel mm API to do that?

Basically when a graphics object is created, space is allocated either in on-card video RAM or in a backup object in system RAM. That backup object can optionally be flipped into the AGP aperture for fast and linear graphics card access.

What I want to do is to be able to release backup object pages while maintaining the contents. Basically hand them over to the swapping system and get a handle back that can be used for later retrieval. The driver will unmap all mappings referencing the page before handing it over to the swapping system.

Is there an API for this and is there any chance of getting it exported?

I suspect you will run into a few troubles trying to do it all in kernel. It might be possible, but probably not with the current code, and it isn't clear we'd want to make the required changes to support such a thing.

Your best bet might be to have a userspace "memory manager" process, which allocates pages (anonymous or file backed), and has your device driver access them with get_user_pages. The get_user_pages takes care of faulting the pages back in, and when they are released, the memory manager will swap them out on demand.

If you need for the driver to *then* export these pages out to be mapped by other processes in userspace, I think you run into problems if trying to use nopage. You'll need to go the nopfn route (and thus your mappings must disallow PROT_WRITE && MAP_PRIVATE).

But I think that might just work?

Quoted 7 lines · Nick Piggin

If you need for the driver to *then* export these pages out to be mapped by other processes in userspace, I think you run into problems if trying to use nopage. You'll need to go the nopfn route (and thus your mappings must disallow PROT_WRITE && MAP_PRIVATE).

But I think that might just work?

Yes, possibly. What kind of problems would I expect if using nopage? Is it, in particular, legal for a process to call get_user_pages() with the tsk and mm arguments of another process?

Quoted 11 lines · Thomas Hellstrom

Quoted 7 lines · Nick Piggin

If you need for the driver to *then* export these pages out to be mapped by other processes in userspace, I think you run into problems if trying to use nopage. You'll need to go the nopfn route (and thus your mappings must disallow PROT_WRITE && MAP_PRIVATE).

But I think that might just work?

Yes, possibly. What kind of problems would I expect if using nopage? Is it, in particular, legal for a process to call get_user_pages() with the tsk and mm arguments of another process?

Oh that is legal. What I'm thinking you'd have problems with is one process having its pages imported to the kernel via get_user_pages, then exported again via an mmap()able device node.

If another process mmaps these pages, you could easily get various problems like PageAnon being set for a file backed page, or rmap structures set up incorrectly for the page. It has been a while since I tried to look at the details, but I would just steer clear of that case.

Using a nopfn handler (instead of nopage) means that the kernel will not look at the backing pages at all.

Your best bet might be to have a userspace "memory manager" process, which allocates pages (anonymous or file backed), and has your device driver access them with get_user_pages. The get_user_pages takes care of faulting the pages back in, and when they are released, the memory manager will swap them out on demand.

Quoted 5 lines · Nick Piggin

Your best bet might be to have a userspace "memory manager" process, which allocates pages (anonymous or file backed), and has your device driver access them with get_user_pages. The get_user_pages takes care of faulting the pages back in, and when they are released, the memory manager will swap them out on demand.

Wouldn't tmpfs be simpler ?