On 21/06/2023 19:51, Thomas Hellström (Intel) wrote:
On 6/21/23 18:35, Ira Weiny wrote:
Thomas Hellström (Intel) wrote:
I think one thing worth mentioning in the context of this patch is that
IIRC kmap_local_page() will block offlining of the mapping CPU until
kunmap_local(), so while I haven't seen any guidelines around the usage
of this api for long-held mappings, I figure it's wise to keep the
mapping duration short, or at least avoid sleeping with a
kmap_local_page() map active.
I figured, while page compression is probably to be considered "slow"
it's probably not slow enough to motivate kmap() instead of
kmap_local_page(), but if anyone feels differently, perhaps it should be
considered.
What you say is all true. But remember the mappings are only actually
created on a HIGHMEM system. HIGHMEM systems are increasingly rare.
Also
they must suffer such performance issues because there is just no other
way around supporting them.
Also Sumitra, and our kmap conversion project in general, is focusing on
not using kmap* if at all possible. Thus the reason V1 tried to use
page_address().
Could we guarantee the i915 driver is excluded from all HIGHMEM systems?
The i915 maintainers might want to chime in here, but I would say no, we
can't, although we don't care much about optimizing for them. Same for
the new xe driver.
AFAIK i915 works on such systems so I don't think we can drop support
just like that. Not sure what the process would be. Perhaps as part of a
wider kernel deprecation would make most sense.
Regards,
Tvrtko
