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

[Jesse Barnes]

On Monday, April 07, 2008 1:46 pm Thomas Hellström wrote:
> > 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...
>
> We want to make the user-space mapping cache-coherent after unbind
> during read, to have any serious read-speed, and the linear kernel map
> has to follow, unless it's non-present. Even if it's non present, we
> need to flush whatever was written through the user-space mapping from
> the cache when rebinding. Having the user-space mapping read-only when
> possible will help avoid this.

Ah, you actually want to *read* from memory?  Yeah that would be really slow 
if we left it UC or WC.  But I thought that was really only necessary for 
relocation, and keithp dealt with that with the "presumed offset" stuff?  Are 
you seeing other cases where we need to read back frequently?

> > 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).
>
> Ouch, so we'll be needing an ioremap_wc(), I guess. We probably
> shouldn't use the linear kernel map for this anyway, since that would
> require a chipset flush for each ring commit.  We can actually use
> vmap() with a wc page protection for that, but an ioremap_wc() would
> certainly save us a lot of trouble.

Yeah, ioremap_wc is probably the best thing to use in the DRM.  And in AGP 
we'll need to clarify things more, since some drivers can do cacheable 
memory, some want UC, etc.

Thanks,
Jesse
--
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/