Re: [PATCH] x86: create array based interface to change page attribute

[Thomas Hellström]

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@xxxxxxxxxx>
> ---
>  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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/