Re: pat support in the kernel

On Tue, May 20, 2003 at 09:10:18PM +0200, [e-mail] wrote:
> change_page_attr() will already do it for the kernel mappings. Just
> define a PAGE_KERNEL_WC.

correct. that was the intent.

> But the tricky part of it is that you need to make sure all mappings
> to that memory have the same caching attribute, otherwise you invoke
> undefined x86 behaviour and risk cache corruptions on some CPUs. 

yes. implementing the basic PAT support is pretty trivial. it's dealing with these cache attribute issues that is the hard part. 

> For normal memory you would need to find a way to synchronize the
> attributes in all mappers (e.g. setting a flag in struct page or
> similar).

are you refering to generic memory that might have shared mappings between multiple processes? I had really only thought of memory explicitly allocated by a driver and mapped to a process, in which this wouldn't be an issue (or is an issue isolated to the specific driver).

it seems it would be easy enough to add a flag to struct page indicating that any future mappings of this memory must be marked with the given attribute. But you'd need to also worry about previous mappings of that page. wouldn't that require a fairly exhaustive scan of who has the physical memory mapped?

would it make sense to limit this functionality to memory mmapped with MAP_PRIVATE rather than MAP_SHARED?

what if process 1 mapped a region WC, forcing process 2 to later map it the same way even though process 2 doesn't care. then process 1 exits and process 3 decides to map the memory. does the caching attribute remain sticky with process 2 (causing process 3 to also need the memory WC), or revert to cached/whatever when the requestor's mapping is removed?

what if 2 processes ask for conflicting mappings? process 1 wants the framebuffer mapped WC, but process 2 asks for it cacheable. or process 1 maps 1/2 of the framebuffer WC and process 2 asks for the full framebuffer uncached.

a lot of these are corner cases that are unlikely to be desirable, but probably should be protected against.

> For frame buffer you also need to handle it in all mmap'ers
> (like fbcon or /dev/mem). I think handling these generic cases will
> need a few VM changes.

yes, this was the case I was more worried about, but it looks like the case above will have the same issues.

I don't think there's any way currently to determine if anyone already has a mapping to a given address range. And it seems that scanning for pre-existing mappings would be pretty ugly. are there any other suggestions for how to handle this?

Thanks,
Terence