(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 >>>> >>>> >>>> Understood. >>>> >>>>> and then in turn next process like swap in to fill physical frame >>>>> number >>>> 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 >>> finding >>> 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. > https://lkml.org/lkml/2011/8/29/295 > > 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?
