Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
From:   "Fabio M. De Francesco" <fabio.maria.de.francesco@linux.intel.com>
To:     Chris Li <chrisl@kernel.org>
Cc:     Seth Jennings <sjenning@redhat.com>,
        Dan Streetman <ddstreet@ieee.org>,
        Vitaly Wool <vitaly.wool@konsulko.com>,
        Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Ira Weiny <ira.weiny@intel.com>,
        Nhat Pham <nphamcs@gmail.com>,
        Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH] mm/zswap: Replace kmap_atomic() with kmap_local_page()
Date:   Wed, 29 Nov 2023 12:41:13 +0100
Message-ID: <2166103.irdbgypaU6@fdefranc-mobl3>
Organization: intel
In-Reply-To: <CAF8kJuMakA-UbHi4Z5uCtB+6S0vcZiULKXu6GQh+7KBHQSR6Bg@mail.gmail.com>
References: <20231127160058.586446-1-fabio.maria.de.francesco@linux.intel.com>
 <CAF8kJuMakA-UbHi4Z5uCtB+6S0vcZiULKXu6GQh+7KBHQSR6Bg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Chris,

On Monday, 27 November 2023 21:16:56 CET Chris Li wrote:
> Hi Fabio,
>=20
> On Mon, Nov 27, 2023 at 8:01=E2=80=AFAM Fabio M. De Francesco
>=20
> <fabio.maria.de.francesco@linux.intel.com> wrote:
> > kmap_atomic() has been deprecated in favor of kmap_local_page().
> >=20
> > Therefore, replace kmap_atomic() with kmap_local_page() in
> > zswap.c.
> >=20
> > kmap_atomic() is implemented like a kmap_local_page() which also
> > disables page-faults and preemption (the latter only in !PREEMPT_RT
> > kernels).=20

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).
> >=20
> > 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.
>=20
> 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.
>=20
>         if (IS_ENABLED(CONFIG_PREEMPT_RT))
>                 migrate_disable();
>         else
>                 preempt_disable();
>=20
>         pagefault_disable();
>=20

This is what I tried to explain with that sentence. I think you overlooked =
it=20
:)

BTW, please have a look at the Highmem documentation. It has initially been=
=20
written by Peter Z. and I reworked and largely extended it authoring  the=20
patches with my gmail address (6 - 7 different patches, if I remember=20
correctly).

You will find there everything you may want to know about these API and how=
 to=20
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.
=20
> I am tempted to Ack on it. Let me sleep on it a before more. BTW,
> thanks for the patch.
>=20
> Chris