lkml.org 
[lkml]   [2008]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] x86: create array based interface to change page attribute
    Dave Airlie wrote:
    > When cpa was refactored to the new set_memory_ interfaces, it removed
    > a special case fast path for AGP systems, which did a lot of page by page
    > attribute changing and held the flushes until they were finished. The
    > DRM memory manager also required this to get useable speeds.
    >
    > This introduces a new interface, which accepts an array of memory addresses
    > to have attributes changed on and to flush once finished.
    >
    > Further changes to the AGP stack to actually use this interface will be
    > published later.
    >
    > Signed-off-by: Dave Airlie <airlied@redhat.com>
    > ---
    > arch/x86/mm/pageattr-test.c | 12 ++-
    > arch/x86/mm/pageattr.c | 164 +++++++++++++++++++++++++++++++-----------
    > include/asm-x86/cacheflush.h | 3 +
    > 3 files changed, 132 insertions(+), 47 deletions(-)
    >
    ...
    Dave,
    Nice work, but how do we handle highmem pages? I know that they don't
    need any attribute change since they're not in the kernel map, but both
    the AGP module and the DRM memory manager typically hold highmem
    addresses in their arrays, so the code should presumably detect those
    and avoid them?

    Since this is an AGPgart and DRM fastpath, the interface should ideally
    be adapted to match the data structures used by those callers. The
    AGPgart module uses an array of addresses, which effectively stops it
    from using pages beyond the DMA32 limit. The DRM memory manager uses an
    array of struct page pointers, but using that was, If I understand
    things correctly, rejected.

    So, if we, at some point, want to have an AGPgart module capable of
    using anything beyond the DMA32 limit we will end up with an interface
    that doesn't match neither AGPgart nor DRM, for which users the fastpath
    was originally intended.

    /Thomas





    \
     
     \ /
      Last update: 2008-03-31 08:59    [W:2.795 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site