(5/10/12 12:58 AM), Minchan Kim wrote:
On 05/10/2012 10:39 AM, Inki Dae wrote:
Hi Jerome,
-----Original Message-----
From: Jerome Glisse [mailto:j.glisse@xxxxxxxxx]
Sent: Wednesday, May 09, 2012 11:46 PM
To: Inki Dae
Cc: airlied@xxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx;
kyungmin.park@xxxxxxxxxxx; sw0312.kim@xxxxxxxxxxx; linux-mm@xxxxxxxxx
Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
On Wed, May 9, 2012 at 2:17 AM, Inki Dae<inki.dae@xxxxxxxxxxx> wrote:
this feature is used to import user space region allocated by malloc()
or
mmaped into a gem. and to guarantee the pages to user space not to be
swapped out, the VMAs within the user space would be locked and then
unlocked
when the pages are released.
but this lock might result in significant degradation of system
performance
because the pages couldn't be swapped out so we limit user-desired
userptr
size to pre-defined.
Signed-off-by: Inki Dae<inki.dae@xxxxxxxxxxx>
Signed-off-by: Kyungmin Park<kyungmin.park@xxxxxxxxxxx>
Again i would like feedback from mm people (adding cc). I am not sure
Thank you, I missed adding mm as cc.
locking the vma is the right anwser as i said in my previous mail,
userspace can munlock it in your back, maybe VM_RESERVED is better.
I know that with VM_RESERVED flag, also we can avoid the pages from being
swapped out. but these pages should be unlocked anytime we want because we
could allocate all pages on system and lock them, which in turn, it may
result in significant deterioration of system performance.(maybe other
processes requesting free memory would be blocked) so I used VM_LOCKED flags
instead. but I'm not sure this way is best also.
Anyway even not considering that you don't check at all that process
don't go over the limit of locked page see mm/mlock.c RLIMIT_MEMLOCK
Thank you for your advices.
for how it's done. Also you mlock complete vma but the userptr you get
might be inside say 16M vma and you only care about 1M of userptr, if
you mark the whole vma as locked than anytime a new page is fault in
the vma else where than in the buffer you are interested then it got
allocated for ever until the gem buffer is destroy, i am not sure of
what happen to the vma on next malloc if it grows or not (i would
think it won't grow at it would have different flags than new
anonymous memory).
I don't know history in detail because you didn't have sent full patches to linux-mm and
I didn't read the below code, either.
Just read your description and reply of Jerome. Apparently, there is something I missed.
Your goal is to avoid swap out some user pages which is used in kernel at the same time. Right?
Let's use get_user_pages. Is there any issue you can't use it?
Maybe because get_user_pages() is fork unsafe? dunno.
It increases page count so reclaimer can't swap out page.
Isn't it enough?
Marking whole VMA into MLCOKED is overkill.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
