|
@@ -100,3 +100,29 @@ allocated by dma_alloc_attrs() function from individual pages if it can
|
|
be mapped as contiguous chunk into device dma address space. By
|
|
be mapped as contiguous chunk into device dma address space. By
|
|
specifying this attribute the allocated buffer is forced to be contiguous
|
|
specifying this attribute the allocated buffer is forced to be contiguous
|
|
also in physical memory.
|
|
also in physical memory.
|
|
|
|
+
|
|
|
|
+DMA_ATTR_ALLOC_SINGLE_PAGES
|
|
|
|
+---------------------------
|
|
|
|
+
|
|
|
|
+This is a hint to the DMA-mapping subsystem that it's probably not worth
|
|
|
|
+the time to try to allocate memory to in a way that gives better TLB
|
|
|
|
+efficiency (AKA it's not worth trying to build the mapping out of larger
|
|
|
|
+pages). You might want to specify this if:
|
|
|
|
+- You know that the accesses to this memory won't thrash the TLB.
|
|
|
|
+ You might know that the accesses are likely to be sequential or
|
|
|
|
+ that they aren't sequential but it's unlikely you'll ping-pong
|
|
|
|
+ between many addresses that are likely to be in different physical
|
|
|
|
+ pages.
|
|
|
|
+- You know that the penalty of TLB misses while accessing the
|
|
|
|
+ memory will be small enough to be inconsequential. If you are
|
|
|
|
+ doing a heavy operation like decryption or decompression this
|
|
|
|
+ might be the case.
|
|
|
|
+- You know that the DMA mapping is fairly transitory. If you expect
|
|
|
|
+ the mapping to have a short lifetime then it may be worth it to
|
|
|
|
+ optimize allocation (avoid coming up with large pages) instead of
|
|
|
|
+ getting the slight performance win of larger pages.
|
|
|
|
+Setting this hint doesn't guarantee that you won't get huge pages, but it
|
|
|
|
+means that we won't try quite as hard to get them.
|
|
|
|
+
|
|
|
|
+NOTE: At the moment DMA_ATTR_ALLOC_SINGLE_PAGES is only implemented on ARM,
|
|
|
|
+though ARM64 patches will likely be posted soon.
|