Driver-driven paging?

Driver-driven paging?

[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?

Regards,
Thomas

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Driver-driven paging?

[Nick Piggin]

Thomas Hellstrom wrote:
> 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?

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Driver-driven paging?

[Thomas Hellström]

Nick Piggin wrote:

> Thomas Hellstrom wrote:
>
>> 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.
>
Hi!

I was actually thinking of something similar, but I thought it would be 
cleaner to do it in the kernel, if the API were there. But currently the 
DRM needs a "master" user-space process anyway so it's a feasible way to go.

> 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?

Thanks,

Thomas



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Driver-driven paging?

[Nick Piggin]

Thomas Hellstrom wrote:
> Nick Piggin wrote:

>> 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.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Driver-driven paging?

[Thomas Hellström]

Nick Piggin wrote:

> Thomas Hellstrom wrote:
>
>> Nick Piggin wrote:
>
>
>>> 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.
>
Thanks. I see what you mean.

Taking into account that we may need special pages on some architectures 
to flip them into the AGP aperture, I might have to do a content copy 
anyway...

/Thomas

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Driver-driven paging?

[Rik van Riel]

Nick Piggin wrote:

> 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 ?

-- 
Who do you trust?
The people with all the right answers?
Or the people with the right questions?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Driver-driven paging?

[Nick Piggin]

Rik van Riel wrote:

> Nick Piggin wrote:
>
>> 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 ?


It could be... actually having the pages inserted into a tmpfs filesystem
by the kernel does sound better than having it try to use the swap code
directly. I still don't know that tmpfs could quite handle that yet, but it
does sound like an interesting avenue (or maybe making your own filesystem
using some tmpfs interfaces). Good idea.

For an initial cut, I think having a memory manager process will work today,
and should do everything needed. So it might be a good way to quickly
evaluate the functionality.

--

Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>