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

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Monday, April 07, 2008 12:51 pm Thomas Hellström wrote:
> > Hopefully the WC stuff will be upstream right after 2.6.25 comes out. 
> > Any reason why we shouldn't keep the pages mapped in the kernel as WC
> > assuming the interface is there?
>
> If the pages are unmapped, we can get reasonable speed doing
> unbind-read-bind operations, kernel accesses to the memory will need to
> use an iomap_atomic_prot_pfn() type of operation.
> No IPI global tlb flushes needed for kernel mapping changes during
> unbind-read-bind and no cache flushes needed either if we write-protect
> the user-space mappings properly, or very limited cache flushes if we
> keep dirty-written-while-cached flags for each page.
>
> If the pages are wc-d we'll need two extra IPI global tlb flushes and a
> buffer-size cache flush every time we do unbind-read-bind, but OTOH we
> don't need the iomap_atomic_prot_pfn() to access single pages from the
> kernel.

Why would we need to flush at all at unbind-read-bind time?  We should be able 
to leave pages in the WC state even when we unbind them, then when we need to 
bind them back into the GTT they'll be ready, but maybe I'm misunderstanding 
you here...

> > Also, to make the API readable, we'd probably want to split the function
> > into kernel_map_pages(..., enum memory_type type) and
> > kernel_unmap_pages(...) (though like I said I think we really should be
> > mapping them WC not umapping them altogether, since we do want to hit the
> > ring buffer from the kernel with the WC type for example).
>
> I think ring-buffers are using ioremap() or vmap() already today. We can
> use these to get WC-type access also in the future. The only time we use
> the linear kernel mapping today is for single page access while patching
> up command buffers.

Yeah, they're ioremapped now, but that's a problem since with the PAT patches 
they'll be mapped hard UC (right now it just happens to work).

Thanks,
Jesse