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:0.242 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site