[PATCH 2/2 v3] drm/exynos: added userptr feature.

[KOSAKI Motohiro]

(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 at gmail.com]
>>> Sent: Wednesday, May 09, 2012 11:46 PM
>>> To: Inki Dae
>>> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
>>> kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-mm at kvack.org
>>> Subject: Re: [PATCH 2/2 v3] drm/exynos: added userptr feature.
>>>
>>> On Wed, May 9, 2012 at 2:17 AM, Inki Dae<inki.dae at samsung.com>  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 at samsung.com>
>>>> Signed-off-by: Kyungmin Park<kyungmin.park at samsung.com>
>>>
>>>
>>> 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.
>