Does get_user_pages_fast lock the user pages in memory in my case?

"
+/**
+ * get_user_pages_fast() - pin user pages in memory

+ * @start:     starting user address
+ * @nr_pages:  number of pages from start to pin
+ * @write:     whether pages will be written to
+ * @pages:     array that receives pointers to the pages pinned.
+ *             Should be at least nr_pages long.

"

But after I digged the code of kswap and the get_user_pages(called by
get_user_pages_fast),
I did not find how the pages pinned in memory.I really need the pages pinned in memory.

Assume page A is one of the pages obtained by get_user_pages_fast()
during page-fault.

[1] page A will on the LRU_ACTIVE_ANON list;
the _count of page A increment by one;
PTE for page A will be set ACCESSED.

[2] kswapd will scan the lru list,and move page A from LRU_ACTIVE_ANON to LRU_INACTIVE_ANON.
In the shrink_page_list(), there is nothing can stop page A been
swapped out.
I don't think the page_reference() can move page A back to
LRU_ACTIVE_ANON.In my driver,
I am not sure if the VLC can access the page A.

Is this a bug? or I miss something?
Thanks .

Hi

Quoted 28 lines

"
+/**
+ * get_user_pages_fast() - pin user pages in memory

+ * @start:     starting user address
+ * @nr_pages:  number of pages from start to pin
+ * @write:     whether pages will be written to
+ * @pages:     array that receives pointers to the pages pinned.
+ *             Should be at least nr_pages long.

"

But after I digged the code of kswap and the get_user_pages(called by
get_user_pages_fast),
I did not find how the pages pinned in memory.I really need the pages pinned in memory.

Assume page A is one of the pages obtained by get_user_pages_fast()
during page-fault.

[1] page A will on the LRU_ACTIVE_ANON list;
the _count of page A increment by one;
PTE for page A will be set ACCESSED.

[2] kswapd will scan the lru list,and move page A from LRU_ACTIVE_ANON to LRU_INACTIVE_ANON. In the shrink_page_list(), there is nothing can stop page A been
swapped out.
I don't think the page_reference() can move page A back to
LRU_ACTIVE_ANON.In my driver,
I am not sure if the VLC can access the page A.

Quoted 3 lines

Is this a bug? or I miss something?
Thanks .

BUG.

We are talking about it just now.

see the following thread in lkml
"[RFC][PATCH 0/6] IO pinning(get_user_pages()) vs fork race fix"

but unfortunately, we don't have no painful fix. perhaps you need change your code...

I'm writting a driver for a video card with the V4L2 interface . V4L2 interface supports the USER-POINTER method for the video frame
handling.

VLC player supports the USER-POINTER method,while MPALYER does not.

In the USER-POINTER method, VLC will call the posix_memalign() to
allocate
203 pages in certain PAL mode (that is 720*576*2) for a single frame.
In my driver , I call the get_user_pages_fast() to obtain the pages
array,and then call
the vmap() to map the pages to VMALLOC space for the memcpy().The code shows below:

   ....................
   get_user_pages_fast();
   ...
   f->data = vmap();
   .......................

In comments, it said :
"
+/**
+ * get_user_pages_fast() - pin user pages in memory

+ * @start:     starting user address
+ * @nr_pages:  number of pages from start to pin
+ * @write:     whether pages will be written to
+ * @pages:     array that receives pointers to the pages pinned.
+ *             Should be at least nr_pages long.

"

But after I digged the code of kswap and the get_user_pages(called by
get_user_pages_fast),
I did not find how the pages pinned in memory.I really need the pages pinned in memory.

Assume page A is one of the pages obtained by get_user_pages_fast()
during page-fault.

[1] page A will on the LRU_ACTIVE_ANON list;
the _count of page A increment by one;
PTE for page A will be set ACCESSED.

[2] kswapd will scan the lru list,and move page A from LRU_ACTIVE_ANON to LRU_INACTIVE_ANON.
In the shrink_page_list(), there is nothing can stop page A been
swapped out.
I don't think the page_reference() can move page A back to
LRU_ACTIVE_ANON.In my driver,
I am not sure if the VLC can access the page A.

Is this a bug? or I miss something?
Thanks .

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

Quoted 12 lines · On Fri, 17 Apr 2009 15:01:01 +0800 Huang Shijie <[email protected]> wrote:

I'm writting a driver for a video card with the V4L2 interface . V4L2 interface supports the USER-POINTER method for the video frame
handling.

VLC player supports the USER-POINTER method,while MPALYER does not.

In the USER-POINTER method, VLC will call the posix_memalign() to
allocate
203 pages in certain PAL mode (that is 720*576*2) for a single frame.
In my driver , I call the get_user_pages_fast() to obtain the pages
array,and then call
the vmap() to map the pages to VMALLOC space for the memcpy().The code shows below:

Quoted 6 lines

   ....................
   get_user_pages_fast();
   ...
   f->data = vmap();
   .......................

What I understand is that you get the pages of posix_memalign by get_user_pages_fast and then that pages are mapped at kernel vmalloc space by vmap.

Is it for removing copy overhead from kernel to user ?

Quoted 29 lines

In comments, it said :
"
+/**
+ * get_user_pages_fast() - pin user pages in memory

+ * @start:     starting user address
+ * @nr_pages:  number of pages from start to pin
+ * @write:     whether pages will be written to
+ * @pages:     array that receives pointers to the pages pinned.
+ *             Should be at least nr_pages long.

"

But after I digged the code of kswap and the get_user_pages(called by
get_user_pages_fast),
I did not find how the pages pinned in memory.I really need the pages pinned in memory.

Assume page A is one of the pages obtained by get_user_pages_fast()
during page-fault.

[1] page A will on the LRU_ACTIVE_ANON list;
the _count of page A increment by one;
PTE for page A will be set ACCESSED.

[2] kswapd will scan the lru list,and move page A from LRU_ACTIVE_ANON to LRU_INACTIVE_ANON. In the shrink_page_list(), there is nothing can stop page A been
swapped out.
I don't think the page_reference() can move page A back to
LRU_ACTIVE_ANON.In my driver,
I am not sure if the VLC can access the page A.

Quoted 3 lines

Is this a bug? or I miss something?
Thanks .

If above my assumption is right, It's not a BUG. You get the application's pages by get_user_pages_fast. 'Page pinning' means it shouldn't be freed. Application's pages always can be swapped out. If you don't want to swap out the page, you should use mlock. If you use mlock, kernel won't insert the page to lru [in]active list. So the page never can be swapped out.

Minchan Kim a??e??:

Quoted 28 lines

Quoted 13 lines · On Fri, 17 Apr 2009 15:01:01 +0800 Huang Shijie <[email protected]> wrote:

I'm writting a driver for a video card with the V4L2 interface . V4L2 interface supports the USER-POINTER method for the video frame
handling.

VLC player supports the USER-POINTER method,while MPALYER does not.

In the USER-POINTER method, VLC will call the posix_memalign() to
allocate
203 pages in certain PAL mode (that is 720*576*2) for a single frame.
In my driver , I call the get_user_pages_fast() to obtain the pages
array,and then call
the vmap() to map the pages to VMALLOC space for the memcpy().The code shows below:

Quoted 6 lines

   ....................
   get_user_pages_fast();
   ...
   f->data = vmap();
   .......................

What I understand is that you get the pages of posix_memalign by get_user_pages_fast and then that pages are mapped at kernel vmalloc space by vmap.

Quoted 3 lines

Is it for removing copy overhead from kernel to user ?

I need a large range of virtual contigous memory to store my video frame(about 203 pages). When I received a full frame ,I will queue the buffer in
a VIDIOC queue,which will be remove by the VIDIOC_DQBUF.'

Quoted 35 lines

Quoted 31 lines

In comments, it said :
"
+/**
+ * get_user_pages_fast() - pin user pages in memory

+ * @start:     starting user address
+ * @nr_pages:  number of pages from start to pin
+ * @write:     whether pages will be written to
+ * @pages:     array that receives pointers to the pages pinned.
+ *             Should be at least nr_pages long.

"

But after I digged the code of kswap and the get_user_pages(called by
get_user_pages_fast),
I did not find how the pages pinned in memory.I really need the pages pinned in memory.

Assume page A is one of the pages obtained by get_user_pages_fast()
during page-fault.

[1] page A will on the LRU_ACTIVE_ANON list;
the _count of page A increment by one;
PTE for page A will be set ACCESSED.

[2] kswapd will scan the lru list,and move page A from LRU_ACTIVE_ANON to LRU_INACTIVE_ANON.
In the shrink_page_list(), there is nothing can stop page A been
swapped out.
I don't think the page_reference() can move page A back to
LRU_ACTIVE_ANON.In my driver,
I am not sure if the VLC can access the page A.

Quoted 3 lines

Is this a bug? or I miss something?
Thanks .

Quoted 9 lines

If above my assumption is right, It's not a BUG.
You get the application's pages by get_user_pages_fast. 'Page pinning' means it shouldn't be freed.
Application's pages always can be swapped out.
If you don't want to swap out the page, you should use mlock. If you use mlock, kernel won't insert the page to lru [in]active list. So the page never can be swapped out.

Yes, it not a bug .

I read the kernel code again. In my case ,the kernel will pin the pages in memory.
I missed function is_page_cache_freeable() in the pageout().

In my case, is_page_cache_freeable()will return false ,for page_count(page) is 3 now:
<1> one is from alloc_page_* in page fault.
<2> one is from get_usr_pages()
<3> one is from add_to_swap() in shrink_page_list()

So ,there is no need to use the mlock, it will mess my driver. is_page_cache_freeable()will return PAGE_KEEP, and page is locked in swap cache.

Unfortunately, the page is unmaped, and the PTE of the page has been replaced by a swp_entry_t .
When the process read the page ,it will raise a page fault again, the kernel will find the page in the
swap cache, and requeue the page in LRU_ACTIVE_ANON, ---I think it is a vicious circle for the kernel.

I think there two places to put back the gup() pages. <1> isolate_page_glable()
<2> in the shrink_page_list(), before called the try_to_unmap(). KOSAKI Motohiro 's patch takes effect in the second place. I think the first place is better.

Quoted 32 lines · On Mon, 20 Apr 2009 10:15:55 +0800 Huang Shijie <[email protected]> wrote:

Minchan Kim a??e??:

Quoted 30 lines

Quoted 12 lines · On Fri, 17 Apr 2009 15:01:01 +0800 Huang Shijie <[email protected]> wrote:

I'm writting a driver for a video card with the V4L2 interface . V4L2 interface supports the USER-POINTER method for the video frame
handling.

VLC player supports the USER-POINTER method,while MPALYER does not.

In the USER-POINTER method, VLC will call the posix_memalign() to
allocate
203 pages in certain PAL mode (that is 720*576*2) for a single frame.
In my driver , I call the get_user_pages_fast() to obtain the pages
array,and then call
the vmap() to map the pages to VMALLOC space for the memcpy().The code shows below:

Quoted 7 lines

   ....................
   get_user_pages_fast();
   ...
   f->data = vmap();
   .......................

What I understand is that you get the pages of posix_memalign by get_user_pages_fast and then that pages are mapped at kernel vmalloc space by vmap.

Is it for removing copy overhead from kernel to user ?

Quoted 3 lines

I need a large range of virtual contigous memory to store my video frame(about 203 pages). When I received a full frame ,I will queue the buffer in a VIDIOC queue,which will be remove by the VIDIOC_DQBUF.'

I can't understand your point. Sorry for that.

Could you explain more detail relation (user buffer which is allocated by posix_memalign) and (kernel buffer which is mapped by vmap) ?

Quoted 43 lines

Quoted 29 lines

Quoted 29 lines

In comments, it said :
"
+/**
+ * get_user_pages_fast() - pin user pages in memory

+ * @start:     starting user address
+ * @nr_pages:  number of pages from start to pin
+ * @write:     whether pages will be written to
+ * @pages:     array that receives pointers to the pages pinned.
+ *             Should be at least nr_pages long.

"

But after I digged the code of kswap and the get_user_pages(called by
get_user_pages_fast),
I did not find how the pages pinned in memory.I really need the pages pinned in memory.

Assume page A is one of the pages obtained by get_user_pages_fast()
during page-fault.

[1] page A will on the LRU_ACTIVE_ANON list;
the _count of page A increment by one;
PTE for page A will be set ACCESSED.

[2] kswapd will scan the lru list,and move page A from LRU_ACTIVE_ANON to LRU_INACTIVE_ANON. In the shrink_page_list(), there is nothing can stop page A been
swapped out.
I don't think the page_reference() can move page A back to
LRU_ACTIVE_ANON.In my driver,
I am not sure if the VLC can access the page A.

Quoted 9 lines

Quoted 4 lines

Is this a bug? or I miss something?
Thanks .

If above my assumption is right, It's not a BUG. You get the application's pages by get_user_pages_fast. 'Page pinning' means it shouldn't be freed. Application's pages always can be swapped out. If you don't want to swap out the page, you should use mlock. If you use mlock, kernel won't insert the page to lru [in]active list. So the page never can be swapped out.

Yes, it not a bug .

I read the kernel code again. In my case ,the kernel will pin the pages in memory. I missed function is_page_cache_freeable() in the pageout().

Quoted 5 lines

In my case, is_page_cache_freeable()will return false ,for page_count(page) is 3 now:
<1> one is from alloc_page_* in page fault.
<2> one is from get_usr_pages()
<3> one is from add_to_swap() in shrink_page_list()

One more, try_to_unmap will call page_cache_release. So, count is 2.

Quoted 4 lines

So ,there is no need to use the mlock, it will mess my driver. is_page_cache_freeable()will return PAGE_KEEP, and page is locked in swap cache.

I can't understand your point exactly yet.
But what I mean is following as in user mode

posix_memalignq(&buffer);
mlock(buffer, buffer_len);

I will not dirty your driver. Do I miss something ?

Quoted 4 lines

Unfortunately, the page is unmaped, and the PTE of the page has been replaced by a swp_entry_t . When the process read the page ,it will raise a page fault again, the kernel will find the page in the swap cache, and requeue the page in LRU_ACTIVE_ANON, ---I think it is a vicious circle for the kernel.

Quoted 14 lines

I think there two places to put back the gup() pages. <1> isolate_page_glable()
<2> in the shrink_page_list(), before called the try_to_unmap(). KOSAKI Motohiro 's patch takes effect in the second place. I think the first place is better.

Quoted 7 lines

I can't understand your point exactly yet.
But what I mean is following as in user mode

posix_memalignq(&buffer);
mlock(buffer, buffer_len);

I also wish the VLC use the mlock,but it does not.If it uses mlock(), the pages will be put in LRU_UNEVICETABL LIST.

Maybe the programmer of VLC thinks: Why i add mlock, for the kernel has the gup() which could pin the pages in memory?

Quoted 3 lines

I will not dirty your driver.
Do I miss something ?

I did add the Mlock bit to the VMA->vm_flags in my driver before,but I think that's ugly.

Minchan Kim a??e??:

Quoted 44 lines

Quoted 30 lines · On Mon, 20 Apr 2009 10:15:55 +0800 Huang Shijie <[email protected]> wrote:

Minchan Kim a??e??:

Quoted 28 lines

Quoted 13 lines · On Fri, 17 Apr 2009 15:01:01 +0800 Huang Shijie <[email protected]> wrote:

I'm writting a driver for a video card with the V4L2 interface . V4L2 interface supports the USER-POINTER method for the video frame
handling.

VLC player supports the USER-POINTER method,while MPALYER does not.

In the USER-POINTER method, VLC will call the posix_memalign() to
allocate
203 pages in certain PAL mode (that is 720*576*2) for a single frame.
In my driver , I call the get_user_pages_fast() to obtain the pages
array,and then call
the vmap() to map the pages to VMALLOC space for the memcpy().The code shows below:

Quoted 7 lines

   ....................
   get_user_pages_fast();
   ...
   f->data = vmap();
   .......................

What I understand is that you get the pages of posix_memalign by get_user_pages_fast and then that pages are mapped at kernel vmalloc space by vmap.

Quoted 9 lines

Quoted 4 lines

Is it for removing copy overhead from kernel to user ?

I need a large range of virtual contigous memory to store my video frame(about 203 pages). When I received a full frame ,I will queue the buffer in
a VIDIOC queue,which will be remove by the VIDIOC_DQBUF.'

Quoted 6 lines

I can't understand your point.
Sorry for that.

Could you explain more detail relation (user buffer which is allocated by posix_memalign) and (kernel buffer which is mapped by vmap) ?

:) sorry for my poor english.
[1] VLC uses the posix_memalign to allocate a big buffer for a single frame(203 pages).
[2] vmap sets up the mapping of virtual contigous address for gup()'s pages array(the pages are not consecutive).
memcpy() needs a contiguous address to copy in kernel mode.
[3] my driver do some specail operations to received data, then memcopy the data to the buffer get in step [2].
[4] when the buffer is full ,I will give the the user process (VLC).

That's all.

It's rather awkward use case of get_user_pages.

If you want to share one big buffer between kernel and user, You can vmalloc and remap_pfn_range.
You can refer cpia_mmap in drivers/media/video/cpia.c

On Mon, 20 Apr 2009 11:28:00 +0800
Huang Shijie <[email protected]> wrote:

I will summarize your method. Is right ?

kernel(driver) application

posix_memalign(buffer) ioctl(buffer)

ioctl handler
get_user_pages(pages);
/* This pages are mapped at user's vma' address space */ vaddr = vmap(pages);
/* This pages are mapped at vmalloc space */
.
.
<after sometime, It may change to other process context>
.
.
interrupt handler in your driver memcpy(vaddr, src, len); notify_user();

						processing(buffer);

It's rather awkward use case of get_user_pages.

If you want to share one big buffer between kernel and user, You can vmalloc and remap_pfn_range.

You can refer cpia_mmap in drivers/media/video/cpia.c

Quoted 62 lines

Minchan Kim a??e??:

Quoted 41 lines

Quoted 36 lines · On Mon, 20 Apr 2009 10:15:55 +0800 Huang Shijie <[email protected]> wrote:

Minchan Kim a??e??:

Quoted 33 lines

Quoted 12 lines · On Fri, 17 Apr 2009 15:01:01 +0800 Huang Shijie <[email protected]> wrote:

I'm writting a driver for a video card with the V4L2 interface . V4L2 interface supports the USER-POINTER method for the video frame
handling.

VLC player supports the USER-POINTER method,while MPALYER does not.

In the USER-POINTER method, VLC will call the posix_memalign() to
allocate
203 pages in certain PAL mode (that is 720*576*2) for a single frame.
In my driver , I call the get_user_pages_fast() to obtain the pages
array,and then call
the vmap() to map the pages to VMALLOC space for the memcpy().The code shows below:

Quoted 8 lines

   ....................
   get_user_pages_fast();
   ...
   f->data = vmap();
   .......................

What I understand is that you get the pages of posix_memalign by get_user_pages_fast and then that pages are mapped at kernel vmalloc space by vmap.

Is it for removing copy overhead from kernel to user ?

Quoted 10 lines

Quoted 4 lines

I need a large range of virtual contigous memory to store my video frame(about 203 pages). When I received a full frame ,I will queue the buffer in a VIDIOC queue,which will be remove by the VIDIOC_DQBUF.'

I can't understand your point. Sorry for that.

Could you explain more detail relation (user buffer which is allocated by posix_memalign) and (kernel buffer which is mapped by vmap) ?

:) sorry for my poor english.
[1] VLC uses the posix_memalign to allocate a big buffer for a single frame(203 pages).
[2] vmap sets up the mapping of virtual contigous address for gup()'s pages array(the pages are not consecutive). memcpy() needs a contiguous address to copy in kernel mode.
[3] my driver do some specail operations to received data, then memcopy the data to the buffer get in step [2].
[4] when the buffer is full ,I will give the the user process (VLC).

That's all.

The v4l2 method IO_METHOD_MMAP does use the vmaloc() method you told above , our driver also support this method,we user vmalloc /remap_vmalloc_range().

But the v4l2 method IO_METHOD_USERPTR must use the method I told above.

Quoted 5 lines

The v4l2 method IO_METHOD_MMAP does use the vmaloc() method you told above , our driver also support this method,we user vmalloc /remap_vmalloc_range().

But the v4l2 method IO_METHOD_USERPTR must use the method I told above.

I guess you mean IO_METHOD_USERPTR can't use remap_vmalloc_range, right?

we need explanation of v4l2 requirement.

Can you explain why v4l2 use two different way? Why application developer need two way?

http://v4l2spec.bytesex.org/spec/r13696.htm
shows the vidioc_reqbufs(). It determines the method of IO : "Memory Mapping or User Pointer I/O"

The application developers can support any methodes of the Two, there is no mandatory request to realize
both methods. For example, the Mplayer only support the "memory
maping" method ,and it does't support the "user pointer", while the VLC supports both.

Quoted 7 lines

http://v4l2spec.bytesex.org/spec/r13696.htm
shows the vidioc_reqbufs(). It determines the method of IO : "Memory Mapping or User Pointer I/O"

The application developers can support any methodes of the Two, there is no mandatory request to realize
both methods. For example, the Mplayer only support the "memory maping" method ,and it does't support the "user pointer",
while the VLC supports both.

I greped VIDIOC_REQBUFS on current tree.
Almost driver has following check.

        if (rb->memory != V4L2_MEMORY_MMAP)
		return -EINVAL;

IOW, almost one don't provide V4L2_MEMORY_USERPTR method. Thus, I think any userland application don't want use V4L2_MEMORY_USERPTR. I recommend you also return -EINVAL.

I think we can't implement V4L2_MEMORY_USERPTR properly. it is mistake by specification.

In the V4L2_MEMORY_USERPTR method, what I want to do is pin the anonymous pages in memory.

I used to add the VM_LOCKED to vma associated with the pages.In my opinion, the pages will:
LRU_ACTIVE_ANON ---> LRU_INACTIVE_ANON---> LRU_UNEVICTABLE

so the pages are pinned in memory.It was ugly, but it works I think. Do you have any suggestions about this method?

Quoted 5 lines

In the V4L2_MEMORY_USERPTR method, what I want to do is pin the anonymous pages in memory.

I used to add the VM_LOCKED to vma associated with the pages.In my opinion, the pages will:
LRU_ACTIVE_ANON ---> LRU_INACTIVE_ANON---> LRU_UNEVICTABLE

Quoted 3 lines

so the pages are pinned in memory.It was ugly, but it works I think. Do you have any suggestions about this method?

page migration (e.g. move_pages) ignore MLOCK.
maybe, VM_LOCKED + gut()ed solved it partially :)

but, user process still can call munlock. it cause disaster. I still think -EINVAL is better.

Quoted 3 lines

but, user process still can call munlock. it cause disaster. I still think -EINVAL is better.

Why the user process call munlock? VLC or Mplayer do not call it, so I don't worry about that.

Our video card is still not on sale.So I can wait until the bug is fixed. :) If there is no method to bypass the problem in future,I will return -EINVAL.

I will read the migration code, I am not clear about why the gup() can stop the migraion.

Minchan Kim a??e??:

Quoted 32 lines

On Mon, 20 Apr 2009 11:28:00 +0800
Huang Shijie <[email protected]> wrote:

I will summarize your method.
Is right ?

kernel(driver) application

posix_memalign(buffer) ioctl(buffer)

ioctl handler
get_user_pages(pages);
/* This pages are mapped at user's vma'
address space */
vaddr = vmap(pages);
/* This pages are mapped at vmalloc space */
.
.
<after sometime,
It may change to other process context>
.
.
interrupt handler in your driver
memcpy(vaddr, src, len);
notify_user();

						processing(buffer);

It's rather awkward use case of get_user_pages.

Quoted 3 lines

If you want to share one big buffer between kernel and user, You can vmalloc and remap_pfn_range.

The v4l2 method IO_METHOD_MMAP does use the vmaloc() method you told above , our driver also support this method,we user vmalloc /remap_vmalloc_range().

But the v4l2 method IO_METHOD_USERPTR must use the method I told above.

Quoted 32 lines · On Mon, 20 Apr 2009 13:05:33 +0800 Huang Shijie <[email protected]> wrote:

Minchan Kim a??e??:

Quoted 30 lines

On Mon, 20 Apr 2009 11:28:00 +0800
Huang Shijie <[email protected]> wrote:

I will summarize your method. Is right ?

kernel(driver) application

posix_memalign(buffer) ioctl(buffer)

ioctl handler
get_user_pages(pages);
/* This pages are mapped at user's vma' address space */ vaddr = vmap(pages);
/* This pages are mapped at vmalloc space */
.
.
<after sometime, It may change to other process context>
.
.
interrupt handler in your driver memcpy(vaddr, src, len); notify_user();

						processing(buffer);

It's rather awkward use case of get_user_pages.

If you want to share one big buffer between kernel and user, You can vmalloc and remap_pfn_range.

Quoted 5 lines

The v4l2 method IO_METHOD_MMAP does use the vmaloc() method you told above , our driver also support this method,we user vmalloc /remap_vmalloc_range().

But the v4l2 method IO_METHOD_USERPTR must use the method I told above.

I can't understand IO_METHOD_USERPTR's benefit compared with IO_METHOD_MMAP. I think both solution can support that application programmer can handle buffer as like pointer and kernel can reduce copy overhead from kernel to user.

Why do you have to support IO_METHOD_USERPTR?

If you can justify your goal, we can add locked GUP.

Quoted 32 lines · On Mon, 20 Apr 2009 10:15:55 +0800 Huang Shijie <[email protected]> wrote:

Minchan Kim a??e??:

Quoted 30 lines

Quoted 12 lines · On Fri, 17 Apr 2009 15:01:01 +0800 Huang Shijie <[email protected]> wrote:

I'm writting a driver for a video card with the V4L2 interface . V4L2 interface supports the USER-POINTER method for the video frame
handling.

VLC player supports the USER-POINTER method,while MPALYER does not.

In the USER-POINTER method, VLC will call the posix_memalign() to
allocate
203 pages in certain PAL mode (that is 720*576*2) for a single frame.
In my driver , I call the get_user_pages_fast() to obtain the pages
array,and then call
the vmap() to map the pages to VMALLOC space for the memcpy().The code shows below:

Quoted 7 lines

   ....................
   get_user_pages_fast();
   ...
   f->data = vmap();
   .......................

What I understand is that you get the pages of posix_memalign by get_user_pages_fast and then that pages are mapped at kernel vmalloc space by vmap.

Is it for removing copy overhead from kernel to user ?

Quoted 3 lines

I need a large range of virtual contigous memory to store my video frame(about 203 pages). When I received a full frame ,I will queue the buffer in a VIDIOC queue,which will be remove by the VIDIOC_DQBUF.'

I can't understand your point. Sorry for that.

Could you explain more detail relation (user buffer which is allocated by posix_memalign) and (kernel buffer which is mapped by vmap) ?

Quoted 40 lines

Quoted 29 lines

Quoted 29 lines

In comments, it said :
"
+/**
+ * get_user_pages_fast() - pin user pages in memory

+ * @start:     starting user address
+ * @nr_pages:  number of pages from start to pin
+ * @write:     whether pages will be written to
+ * @pages:     array that receives pointers to the pages pinned.
+ *             Should be at least nr_pages long.

"

But after I digged the code of kswap and the get_user_pages(called by
get_user_pages_fast),
I did not find how the pages pinned in memory.I really need the pages pinned in memory.

Assume page A is one of the pages obtained by get_user_pages_fast()
during page-fault.

[1] page A will on the LRU_ACTIVE_ANON list;
the _count of page A increment by one;
PTE for page A will be set ACCESSED.

[2] kswapd will scan the lru list,and move page A from LRU_ACTIVE_ANON to LRU_INACTIVE_ANON. In the shrink_page_list(), there is nothing can stop page A been
swapped out.
I don't think the page_reference() can move page A back to
LRU_ACTIVE_ANON.In my driver,
I am not sure if the VLC can access the page A.

Quoted 9 lines

Quoted 4 lines

Is this a bug? or I miss something?
Thanks .

If above my assumption is right, It's not a BUG. You get the application's pages by get_user_pages_fast. 'Page pinning' means it shouldn't be freed. Application's pages always can be swapped out. If you don't want to swap out the page, you should use mlock. If you use mlock, kernel won't insert the page to lru [in]active list. So the page never can be swapped out.

Yes, it not a bug .

Quoted 8 lines

I read the kernel code again. In my case ,the kernel will pin the pages in memory. I missed function is_page_cache_freeable() in the pageout().

In my case, is_page_cache_freeable()will return false ,for page_count(page) is 3 now:
<1> one is from alloc_page_* in page fault.
<2> one is from get_usr_pages()
<3> one is from add_to_swap() in shrink_page_list()

One more, try_to_unmap will call page_cache_release. So, count is 2.

Quoted 4 lines

So ,there is no need to use the mlock, it will mess my driver. is_page_cache_freeable()will return PAGE_KEEP, and page is locked in swap cache.

I can't understand your point exactly yet.
But what I mean is following as in user mode

posix_memalignq(&buffer);
mlock(buffer, buffer_len);

I will not dirty your driver. Do I miss something ?

Quoted 18 lines

Unfortunately, the page is unmaped, and the PTE of the page has been replaced by a swp_entry_t . When the process read the page ,it will raise a page fault again, the kernel will find the page in the swap cache, and requeue the page in LRU_ACTIVE_ANON, ---I think it is a vicious circle for the kernel.

I think there two places to put back the gup() pages. <1> isolate_page_glable()
<2> in the shrink_page_list(), before called the try_to_unmap(). KOSAKI Motohiro 's patch takes effect in the second place. I think the first place is better.

Quoted 4 lines

I read the kernel code again. In my case ,the kernel will pin the pages in memory. I missed function is_page_cache_freeable() in the pageout().

Quoted 5 lines

In my case, is_page_cache_freeable()will return false ,for page_count(page) is 3 now:
<1> one is from alloc_page_* in page fault.
<2> one is from get_usr_pages()
<3> one is from add_to_swap() in shrink_page_list()

One more, try_to_unmap will call page_cache_release. So, count is 2.

Quoted 5 lines

Quoted 5 lines

I read the kernel code again. In my case ,the kernel will pin the pages in memory.
I missed function is_page_cache_freeable() in the pageout().

Quoted 9 lines

Quoted 6 lines

In my case, is_page_cache_freeable()will return false ,for page_count(page) is 3 now:
<1> one is from alloc_page_* in page fault.
<2> one is from get_usr_pages()
<3> one is from add_to_swap() in shrink_page_list()

One more, try_to_unmap will call page_cache_release. So, count is 2.

I found I missed something.When code reachs is_page_cache_freeable(). page_count(page) is 3:

<1> alloc_page_* in page fault . [page count is 1] <2> get_usr_pages().             [page count is 2] <3> isolate_pages_global()       [page count is 3] <4> add_to_swap()                [page count is 4] <5> try_to_unmap()               [page count is 3]

so it not a bug, just a vicious circle.

Do i miss something?

I think there two places to put back the gup() pages. <1> isolate_page_glable()
<2> in the shrink_page_list(), before called the try_to_unmap(). KOSAKI Motohiro 's patch takes effect in the second place. I think the first place is better.