On 26.08.25 10:46, David Hildenbrand wrote: >>> So my assumption would be that that is missing for the drivers here? >> >> Well yes and no. >> >> See the PAT is optimized for applying specific caching attributes to ranges >> [A..B] (e.g. it uses an R/B tree). But what drivers do here is that they >> have single pages (usually for get_free_page or similar) and want to apply a >> certain caching attribute to it. >> >> So what would happen is that we completely clutter the R/B tree used by the >> PAT with thousands if not millions of entries. >> > > Hm, above you're saying that there is no direct map, but now you are saying > that the pages were obtained through get_free_page()?
The problem only happens with highmem pages on 32bit kernels. Those pages are not in the linear mapping. > I agree that what you describe here sounds suboptimal. But if the pages where > obtained from the buddy, there surely is a direct map -- unless we explicitly > remove it :( > > If we're talking about individual pages without a directmap, I would wonder > if they are actually part of a bigger memory region that can just be reserved > in one go (similar to how remap_pfn_range()) would handle it. > > Can you briefly describe how your use case obtains these PFNs, and how > scattered tehy + their caching attributes might be? What drivers do is to call get_free_page() or alloc_pages_node() with the GFP_HIGHUSER flag set. For non highmem pages drivers then calls set_pages_wc/uc() which changes the caching of the linear mapping, but for highmem pages there is no linear mapping so set_pages_wc() or set_pages_uc() doesn't work and drivers avoid calling it. Those are basically just random system memory pages. So they are potentially scattered over the whole memory address space. Regards, Christian.
