lkml.org 
[lkml]   [2012]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [x86 PAT PATCH 0/2] x86 PAT vm_flag code refactoring
Suresh Siddha wrote:
> On Tue, 2012-04-03 at 10:03 +0400, Konstantin Khlebnikov wrote:
>> Suresh Siddha wrote:
>>> Konstantin,
>>>
>>> On Sat, 2012-03-31 at 21:09 +0400, Konstantin Khlebnikov wrote:
>>>> v2: Do not use batched pfn reserving for single-page VMA. This is not optimal
>>>> and breaks something, because I see glitches on the screen with i915/drm driver.
>>>> With this version glitches are gone, and I see the same regions in
>>>> /sys/kernel/debug/x86/pat_memtype_list as before patch. So, please review this
>>>> carefully, probably I'm wrong somewhere, or I have triggered some hidden bug.
>>>
>>> Actually it is not a hidden bug. In the original code, we were setting
>>> VM_PFN_AT_MMAP only for remap_pfn_range() but not for the vm_insert_pfn().
>>> Also the value of 'vm_pgoff' depends on the driver/mmap_region() in the case of
>>> vm_insert_pfn(). But with your proposed code, you were setting
>>> the VM_PAT for the single-page VMA also and end-up using wrong vm_pgoff in
>>> untrack_pfn_vma().
>>
>> But I set correct vma->vm_pgoff together with VM_PAT. But, it shouldn't work if vma is expandable...
>>
>
> Also, I am not sure if we can override vm_pgoff in the fault handling
> path. For example, looking at unmap_mapping_range_tree() it does depend
> on the vm_pgoff value and it might break if we change the vm_pgoff in
> track_pfn_vma_new() (which gets called from vm_insert_pfn() as part of
> the i915_gem_fault()).

Yes, and we shouldn't change vma under mm->mmap_sem read-lock.

>
> thanks,
> suresh
>
>
>



\
 
 \ /
  Last update: 2012-04-04 06:43    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site