On 05/10/2012 04:56 PM, Minchan Kim wrote: > On 05/10/2012 04:31 PM, Kyungmin Park wrote: > >> On 5/10/12, Minchan Kim <minchan@xxxxxxxxxx> wrote: >>> On 05/10/2012 03:53 PM, KOSAKI Motohiro wrote: >>> >>>> (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. >>> >>> >>> If there is such problem, I think user program should handle it by >>> MADV_DONTFORK >>> and make to allow write by only parent process. >> Please read the original patches and discuss the root cause. Does it >> harm to pass user space memory to kernel space and how to make is >> possible at DRM? > > > Where can I read original discussion history? > I am not expert of DRAM so I can answer only mm stuff and it's why Jerome ccing mm-list. ^^^ silly typo DRM -- Kind regards, Minchan Kim _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
