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

Thomas Hellström wrote:
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?

Cache attributes fundamentally work on a mapping and not on physical memory.
(MTRR's are special there, they do work on physical memory, but that's a special case and not relevant here)

So to be honest, your question doesn't make sense; because all I can do is ask "which mapping of these pages".

Even the old interfaces prior to 2.6.24 only managed to deal with SOME of the mappings of a page.
And if/when future CPUs don't require all mappings to be in sync, clearly the kernel will only change
the mapping that is requested as well.



Since this is an AGPgart and DRM fastpath, the interface should ideally be adapted to match the data structures used by those callers.

Actually, the interface has to make sense conceptually convey the right information,
the implementation should not have to second guess internals of AGP/DRM because that
would just be a recipe for disaster.
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.

yes because simply put, if you pass a struct page to such a function, you're not telling it which
mapping or mappings you want changed....
(And if you say "only the 1:1 mapping, so why doesn't the other side calculate that"... there's no speed gain in doing
the calculation for that on the other side of an interface, and that makes it zero reason to misdesign the interface
to only have the "which mapping" information implicit)

--
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/

Relevant Pages

  • Re: [PATCH] x86: create array based interface to change page attribute
    ... a special case fast path for AGP systems, which did a lot of page by page ... This introduces a new interface, which accepts an array of memory addresses ... your question doesn't make sense; because all I can do is ask "which mapping of these pages". ... The DRM memory manager uses an array of struct page pointers, but using that was, If I understand things correctly, rejected. ...
    (Linux-Kernel)
  • Re: [PATCH] x86: create array based interface to change page attribute
    ... 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. ... DRM memory manager also required this to get useable speeds. ... This introduces a new interface, which accepts an array of memory addresses ...
    (Linux-Kernel)
  • Re: [PATCH] x86: create array based interface to chagne page attribute
    ... a special case fast path for AGP systems, which did a lot of page by ... The DRM memory manager also required this to get useable speeds. ... Further changes to the AGP stack to actually use this interface will ...
    (Linux-Kernel)
  • Re: Transaction Oriented Architecture (TOA)
    ... I don't think the issue is ignoring the database; it is recognizing that the database is a different subject matter applying different business rules than the problem solution. ... There is nothing to prevent abstracting the database subject matter in a classic OO manner with objects like Schema, Table, Tuple, and Query. ... I'm of the opinion that the more obvious the database (or at least its interface) is the more easily maintainable an application becomes. ... I've nothing against creating frameworks and patterns to facilitate those programming activities, but prefer the concept of a problem domain transaction to language-specific expressions mapping 1:1 with anything physically present in the database. ...
    (comp.object)
  • Re: Transaction Oriented Architecture (TOA)
    ... Once one is outside the CRUD/USER arena, applications are optimized to solve very specific problems. ... The mapping of the DB is reused--it makes the DB's API more language-malleable, and that's reused everywhere--regardless the application domain. ... You seem to be advocating the creation of a layer between the application the the language-DB interface that maps the application domain objects to the DB--I'm guessing classes to tables, instances to rows, and fields to columns. ... one should be able to solve the customer problem and design the DB access interface without knowing or caring how the stored data is ultimately organized. ...
    (comp.object)