Messages in this thread | | | Date | Mon, 19 Apr 2004 17:54:57 -0500 | From | Terence Ripperda <> | Subject | Re: PAT support |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |