lkml.org 
[lkml]   [2012]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subject[x86 PAT PATCH 0/2] x86 PAT vm_flag code refactoring
    Date
    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().

    We can simplify the track/untrack pfn routines and can remove the
    dependency on vm_pgoff completely. Am appending a patch which does this
    and also modified your x86 PAT patch based on this. Can you please
    check and if you are ok, merge these bits with the rest of your patches.

    thanks,
    suresh
    ---

    Konstantin Khlebnikov (1):
    mm, x86, PAT: rework linear pfn-mmap tracking

    Suresh Siddha (1):
    x86, pat: remove the dependency on 'vm_pgoff' in track/untrack pfn
    vma routines

    arch/x86/mm/pat.c | 38 ++++++++++++++++++++++++--------------
    include/asm-generic/pgtable.h | 4 ++--
    include/linux/mm.h | 15 +--------------
    mm/huge_memory.c | 7 +++----
    mm/memory.c | 15 ++++++++-------
    5 files changed, 38 insertions(+), 41 deletions(-)

    --
    1.7.6.5



    \
     
     \ /
      Last update: 2012-04-03 02:47    [W:3.753 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site