Hello readers! I am currently in my fifth week of the Outreachy internship, where I am working as a Linux-Kernel intern on the project "Converting kmap() and kmap_atomic() call sites to kmap_local_page()".
This blog aims to introduce you to my project and the significance of memory management in modern operating systems.
As part of the Memory Management system's Highmem subsystem, changes are being made to replace the older kmap() and kmap_atomic() functions with the new kmap_local_page() or kmap_local_folio() functions. These functions allow the mapping of physical memory pages into the kernel address space.
The deprecation of kmap() and kmap_atomic() is due to their drawbacks, such as high cost, limited mapping space, the need for a global lock for synchronization, and the possibility of the process sleeping in the absence of free slots. Similarly, kmap_atomic() disables preemption and migration, which can lead to latency, jitters, and system imbalance.
To overcome these issues, the solution lies in using kmap_local_{page, folio}(). These functions offer faster performance, provide thread-local and CPU-local mappings, handle page faults within a local kmap region, and preserve preemption by saving and restoring mappings during context switches.
For more detailed information, you can refer to the documentation available at https://docs.kernel.org/mm/highmem.html.
In my work, I am evaluating various call sites to determine how effectively kmap_local() can be utilized and the deprecated kmap() and kmap_atomic() calls can be eliminated. While some conversions simply involve replacement, others require thorough code analysis and potentially even rearchitecting of the codebase.
NEXT: Conversion from kmap() to kmap_local_page() https://dev.to/heygauri/conversion-from-kmap-to-kmaplocalpage-2hc8
Top comments (0)