Re: PAT support

[Terence Ripperda <tripperda@nvidia.com>]

On Fri, Apr 16, 2004 at 05:42:17PM -0700, ak@muc.de wrote:
> change_page_attr can change more than just caching attributes,
> also read/write (e.g. slab debug uses it for that) 

ah, ok. sorry, missed that.

> At least for the later adding another book keeping data structure
> may be too expensive.

makes sense.

> I think I prefer the do/undo model instead of push/pop.
> That can work with cmaps too. PAGE_KERNEL means no cmap,
> PAGE_KERNEL_WC and PAGE_KERNEL_NOCACHE get a cmap.

but then what is the point of cmap? I would expect a mix of WC and UC mappings to be much less dangerous than a mix of WC/UC and WB. perhaps my mindset is wrong, but it seems allowing ioremap to request a cached mapping is important, and that if that mapping was followed by ioremap_nocached or ioremap_wrcomb, that these subsequent calls should fail.

I did finish implementing your suggestion, that change_page_attr should consider PAGE_KERNEL as a call to cmap_release_range and anything else as a call to cmap_request_range. seemed to work ok, but I'm seeing the acpi table code doing a lot of ioremaps (cached) that are ignored, then iounmaps are causing cmap_release_range calls to complain about not finding the regions. of course in a final version, we'd cut out the debug output, but expecting lots of empty calls to cmap_release_range seems messy.

what if there was a restore_page_attr(unsigned long address, unsigned long numpages) that assumed the pgprot was PAGE_KERNEL. change_page_attr knows to call cmap_request_range and restore_page_attr knows to call cmap_release_range. otherwise they do the same thing, restore_ just inherently uses PAGE_KERNEL for the caching type.

> remove_vm_area() needs to just be split into some worker functions 
> (__remove_vm_area et.al.)

ok, easily done.

Thanks,
Terence