I'm doing this from work, so I am unable to respond to your mail
directly (and I wish I could so I knew exactly what you wrote).
I am unhappy with the idea of GFP_UNCACHED. How do you do this?
On ARM, you cannot change the cache bits on a per-page basis on
the memory returned from get_free_page(), since the kernel pages
are mapped in using sections.
To map these in using the page tables IMHO is very wasteful in
both memory for the extra 1K page tables, and in terms of the
TLB lookups that have to be performed. Obviously this is will
have a severe impact on performance of the system, which I think
that most people will be unwilling to accept unless it's 100%
proven that there is no other way of solving the problem.
Your best bet is to use a variant of vmalloc, which allocates
individual pages in the exact way that vmalloc does, but does
not set the cache bits. This can be done as Phil mentioned
earlier with minimal changes without impacting the other
architectures severely (GCC should optimise the PAGE_KERNEL
constant correctly).
In fact, this sort of architecture dependent cache mapping is
already done in the generic code for mmap()ing an area of
physical address space (mmap_mem in drivers/char/mem.c).
The modification to vmalloc.c appears to be the cleanest and
the easiest, iff the other architecture maintainers are in
agreement.
To sum up, IMHO GFP_UNCACHED is fatally flawed from the beginning
on ARM.
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King rmk@arm.linux.org.uk --- ---
| | | | http://www.arm.linux.org.uk/~rmk/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King rmk@arm.linux.org.uk --- ---
| | | | http://www.arm.linux.org.uk/~rmk/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/