Another reason for kmap_atomic()
Posted Nov 19, 2004 19:55 UTC (Fri) by giraffedata
Parent article: On not getting burned by kmap_atomic()
The article misses the real purpose of kmap_atomic(), which is evident in its name. kmap() can sleep, waiting for a virtual address range to be available. Some callers aren't able to sleep where they call kmap().
kmap_atomic() uses reserve pools of virtual address ranges (page table entries) so that it is always atomic (or fails immediately if the reserve pool is empty). The reason there are multiple pools (chosen by kmap's second argument) is to avoid deadlock. The kmap() succeeding is sometimes a prerequisite to page table entries getting freed up.
Example: Someone does a kmap. System needs to swap out a high memory page to free up a page table entry for the kmap. The swap device can't access high memory, so the device driver has to copy the page to a low memory page "bounce buffer". To do that, it has to kmap both pages. The one reserved bounce buffer PTE slot keeps this from causing a deadlock.
Since these kmappers are always using the same small set of page table entries, it makes an ideal place for a performance improvement with per-cpu page table entries.
to post comments)