Hi Chris, On Monday, 27 November 2023 21:16:56 CET Chris Li wrote: > Hi Fabio, > > On Mon, Nov 27, 2023 at 8:01 AM Fabio M. De Francesco > > <fabio.maria.de.francesco@xxxxxxxxxxxxxxx> wrote: > > kmap_atomic() has been deprecated in favor of kmap_local_page(). > > > > Therefore, replace kmap_atomic() with kmap_local_page() in > > zswap.c. > > > > kmap_atomic() is implemented like a kmap_local_page() which also > > disables page-faults and preemption (the latter only in !PREEMPT_RT > > kernels). Please read again the sentence above. > > The kernel virtual addresses returned by these two API are > > only valid in the context of the callers (i.e., they cannot be handed to > > other threads). > > > > With kmap_local_page() the mappings are per thread and CPU local like > > in kmap_atomic(); however, they can handle page-faults and can be called > > from any context (including interrupts). The tasks that call > > kmap_local_page() can be preempted and, when they are scheduled to run > > again, the kernel virtual addresses are restored and are still valid. > > As far as I can tell, the kmap_atomic() is the same as > kmap_local_page() with the following additional code before calling to > "__kmap_local_page_prot(page, prot)", which is common between these > two functions. > > if (IS_ENABLED(CONFIG_PREEMPT_RT)) > migrate_disable(); > else > preempt_disable(); > > pagefault_disable(); > This is what I tried to explain with that sentence. I think you overlooked it :) BTW, please have a look at the Highmem documentation. It has initially been written by Peter Z. and I reworked and largely extended it authoring the patches with my gmail address (6 - 7 different patches, if I remember correctly). You will find there everything you may want to know about these API and how to do conversions from the older to the newer. Thanks for acking this :) > From the performance perspective, kmap_local_page() does less so it > has some performance gain. I am trying to think would it have another > unwanted side effect of enabling interrupt and page fault while zswap > decompressing a page. > The decompression should not generate page fault. The interrupt > enabling might introduce extra latency, but most of the page fault was > having interrupt enabled anyway. The time spent in decompression is > relatively small compared to the whole duration of the page fault. So > the interrupt enabling during those short windows should be fine. > "Should" is the famous last word. Here, Matthew chimed in to clarify. Thanks Matthew. > I am tempted to Ack on it. Let me sleep on it a before more. BTW, > thanks for the patch. > > Chris
