On Fri, 5 Apr 2013, Laura Abbott wrote: > The highmem code provides kmap_flush_unused to ensure all kmap > mappings are really removed if they are used. This code does not You meant "if they are *not* used", right? > handle kmap_atomic mappings since they are managed separately. > This prevents an issue for any code which relies on having absolutely > no mappings for a particular page. Rather than pay the penalty of > having CONFIG_DEBUG_HIGHMEM on all the time, add functionality > to remove the kmap_atomic mappings in a similar way to kmap_flush_unused. Could you elaborate on that code that relies on having absolutely no mappings for a particular page please? > This is intended to be an RFC to make sure this approach is > reasonable. The goal is to have kmap_atomic_flush_unused be a public > API. The clearing code is going to be costly since you do a set_top_pte(vaddr, __pte(0)) unconditionally on the whole range, regardless if the PTE is already set to 0. Using it via an hotplug callback is rather strange, but I'm assuming that this was only for testing? Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
