Thread (6 messages) 6 messages, 3 authors, 2005-03-25

Re: [PATCH] ppc32/64: Map prefetchable PCI without guarded bit

flat view

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2005-03-25 22:36:28
Also in: lkml

On Thu, 2005-03-24 at 08:54 -0800, Jesse Barnes wrote:
On Wednesday, March 23, 2005 10:24 pm, Benjamin Herrenschmidt wrote:
quoted
While experimenting with framebuffer access performances, we noticed a
very significant improvement in write access to it when not setting
the "guarded" bit on the MMU mappings. This bit basically says that
reads and writes won't have side effects (it allows speculation). It
appears that it also disables write combining.
Doesn't pgprot_writecombine imply non-guarded, so can't you use it instead?  
Either way, you'll probably want to fix fbmem.c as well and turn off 
_PAGE_GUARDED?
I'm not sure we implement pgprot_writecombine. But anyway, that wouldn't
help as X uses /dev/mem which doesn't use that, and sysfs new mmap
interface doesn't have anything for setting writecombine.

The interface I propose could be made generic, that is the whole point.
It's basically a mean for the arch to say "heh, somebody wants to map
this bit of physical address space, what pgprot should I use" :) The
decision of wether to do uncacheable or writecombine, all the
page_in_ram() trickery in /dev/mem or fbmem can be moved to arch
specific routines and cleanup the generic stuff.
Maybe it's time for a more generic call to support this stuff, both for 
in-kernel mappings and ones that we export to userspace.
Yah, in-kernel mappings aren't covered yet, as my interface supposes a
"struct file" but then, I don't use the struct file argument in my ppc
implementation (I exposed it for the sake of archs that may want it). We
could just define that in-kernel mappings can call this with NULL for
struct file.

Ben.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help