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? > > With that said, my Reviewed-by: still stands. Thanks! Ira
