[PATCH 2/2 v3] drm/exynos: added userptr feature.
kosaki.motohiro at gmail.com
Thu May 10 19:51:38 PDT 2012
(5/10/12 8:50 PM), Minchan Kim wrote:
> Hi KOSAKI,
> On 05/11/2012 02:53 AM, KOSAKI Motohiro wrote:
>>>>> let's assume that one application want to allocate user space memory
>>>>> region using malloc() and then write something on the region. as you
>>>>> may know, user space buffer doen't have real physical pages once
>>>>> malloc() call so if user tries to access the region then page fault
>>>>> handler would be triggered
>>>>> and then in turn next process like swap in to fill physical frame
>>>> into entry of the page faulted.
>>>> Sorry, I can't understand your point due to my poor English.
>>>> Could you rewrite it easiliy? :)
>>> Simply saying, handle_mm_fault would be called to update pte after
>>> vma and checking access right. and as you know, there are many cases to
>>> process page fault such as COW or demand paging.
>> Hmm. If I understand correctly, you guys misunderstand mlock. it doesn't
>> page pinning
>> nor prevent pfn change. It only guarantee to don't make swap out. e.g.
> Symantic point of view, you're right but the implementation makes sure page pinning.
>> memory campaction
>> feature may automatically change page physical address.
> I tried it last year but decided drop by realtime issue.
> so I think mlock is a kind of page pinning. If elsewhere I don't realized is doing, that place should be fixed.
> Or my above patch should go ahead.
Thanks pointing out. I didn't realized your patch didn't merged. I think it should go ahead. think autonuma case,
if mlock disable autonuma migration, that's bug. I don't think we can promise mlock don't change physical page.
I wonder if any realtime guys page migration is free lunch. they should disable both auto migration and compaction.
And, think if application explictly use migrate_pages(2) or admins uses cpusets. driver code can't assume such scenario
doesn't occur, yes?
More information about the dri-devel