From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A603CC4167B for ; Wed, 29 Nov 2023 11:41:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A7CF6B03CB; Wed, 29 Nov 2023 06:41:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 157CD6B03CC; Wed, 29 Nov 2023 06:41:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01E596B03CD; Wed, 29 Nov 2023 06:41:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id E53AB6B03CB for ; Wed, 29 Nov 2023 06:41:26 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B76711A04C7 for ; Wed, 29 Nov 2023 11:41:26 +0000 (UTC) X-FDA: 81510801372.15.483A7A2 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) by imf29.hostedemail.com (Postfix) with ESMTP id D87B512000E for ; Wed, 29 Nov 2023 11:41:23 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=H+FNdSMN; spf=none (imf29.hostedemail.com: domain of fabio.maria.de.francesco@linux.intel.com has no SPF policy when checking 198.175.65.10) smtp.mailfrom=fabio.maria.de.francesco@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701258084; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=kiJTXTz4UDFclWho9xeBx/36rju71QIU4DUd59UcG+I=; b=mlQ+W7DuKKv1ArxK3XUQXfzP80IonCb0rmwNhds5YO98eOLYHSj2K7DrjA0ZoK4uqUHp2M 6KWJS33FM+N8m6s3EG9lnDA+Ozf5yp2aCUQ2B1YKrOluYWwp+etDkDu0sdckWSat+LjJlN FZf+arZZyAaDeQhypeDpQ8lL9Jzyl74= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701258084; a=rsa-sha256; cv=none; b=p90aD/Z/seZRdMiZqBX/h+d4jRzc0+6ZPmtrNplPwmJvxIIQar4hecgeo7Edji5CoGesdy PXtEixWek619CcXNpWlRproXLI6ndshDrptkxl138wYbnT/3e1Oi6tjSgj3SEi7MH7RLi6 +RHItntn1Xtf3s+hKS/FA8c8LAwntik= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=H+FNdSMN; spf=none (imf29.hostedemail.com: domain of fabio.maria.de.francesco@linux.intel.com has no SPF policy when checking 198.175.65.10) smtp.mailfrom=fabio.maria.de.francesco@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1701258084; x=1732794084; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=531Qy67F7OZYH+kBShiz0InOyHCpXmDL2JT+KJogS2E=; b=H+FNdSMNVoWemcHEqXnbzA9YU3HK+wmV4KLQZRaOm3cYoWENg69NUans i/teA4Hquq90OM5vMb9V8l+Y3mrzwAuQ/jAm4FtlldgZYr5n2XszMqxpM mgD2CODBfXtbE17IbMcIBBxkwCELoT4StPFMnseAOhOVFLchgO3Uv/7WD HwETRbBiGgAdbw+tKohQYU+XFOkU1YKMQm6vvKVqPycBJdRF+dUzoS+r3 vJmNjvACV4aXSrX/CbiObGuhYCr7igMl9onPjEgBodw0r27BdzPmiGtR0 JmZ0cvhFWzLunpxj8oKNzPnnfihQcDxXhy6WZYiarLP33xI2uRQzfPX7q g==; X-IronPort-AV: E=McAfee;i="6600,9927,10908"; a="6414715" X-IronPort-AV: E=Sophos;i="6.04,235,1695711600"; d="scan'208";a="6414715" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Nov 2023 03:41:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10908"; a="839385780" X-IronPort-AV: E=Sophos;i="6.04,235,1695711600"; d="scan'208";a="839385780" Received: from ksandowi-mobl1.ger.corp.intel.com (HELO fdefranc-mobl3.localnet) ([10.213.31.19]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Nov 2023 03:41:16 -0800 From: "Fabio M. De Francesco" To: Chris Li Cc: Seth Jennings , Dan Streetman , Vitaly Wool , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ira Weiny , Nhat Pham , Matthew Wilcox 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: References: <20231127160058.586446-1-fabio.maria.de.francesco@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: a4xc7b7i39yn4eaix455n1i84afxifgz X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: D87B512000E X-Rspam-User: X-HE-Tag: 1701258083-928564 X-HE-Meta: U2FsdGVkX1/efIxX7uP1VELlx9YWWWbZ/Hd4fI/B+Sb1QIz4S/WWFJT8RLcI0+ZwXmIEi0LtE2B3zwaQu6ehIBSA5SWacSvasaN3xEOjnMZFvUFIFAcjOvS1uRneoLS2Ona87mB5hmIjibx6i1JpViquetjXbIyYjgIc6BJBZtk3JzcWrpxeWPfGIBYfpvkJEl84JXockm1SPLeaBqDpyaJe+7iUc+fAkQ6NboBfuQUaAQKT82vH8Gz+y4cx8hW8bgxQ4iKQuo1QejfWG90Vk1UM0ElPEcFJINLK7Cc/JYZG9iJVwpoGuyA7QmZaXeP6BRPH4ALhowOn4yls0hkFSJgdLrH9VD3QgmrVBnPwdf2GjrQ7w395dTj/4GGV6fzQ4MQP7gypZxjldqzQEEFRlzFgHpAjpI50g4Mz7KaBjFA1OTtLENPxvit1VQfoy+DpMnxzzixSCAINhwDFsO5yZjI1oR6+eDg+0geGYaDkIgf8fEFc/d9AvRM6Y3RN9L38vjNx0OVs2UDWJAHhO9OhpDyLpktMS8WOD/Ahkc3DJ1oVlS4+eZ88SUwK02DFyzdaA/IAnAvE77RxcFuH+PzPCINJCoLeinyKEezGv3L7PCuB+Y5F0ZYBkV4W8+BAZjgw6a5NAmBq7floFm75JXI4+7HcPBzinbK2o9xj+2kanVu3QmTCDruEpNLEoKBNe+ntfUZTNhc7D77OHBZZLGC3XJElXrUlL6bbtbfangLbLslCnn4zj++7GCEpid+H9+euRjEyqGWHnFNB/bqtYbSasQRYh8npbJRTOw1dn5biRHnBNGUXUoY9hhwOLAl9EuUkPlYyCPwRO3x5sAe7fkYhJS3rdJRIJC2s9PvbYdxBr5gHpnginbkQ9Djk/Y9J32xhkLOBnwOnXxk19VGfQoYd9w+Bup2PKghkQSDic+L3Zr6BZ9pu6zALi+PqOWnExNa2rae3lEah8EFamuZ4gOQ KOvVABLf 8RA85z/p8qrc5sNnHIzWHyybRp4215uHDZBzjm2MdLe07Bb0VTDypynHy8K/wV+DtnOQJblYDjmLyRZuhBQylvz4diAKpjzOI3D3Bb37TXwn0guLyO23FQdMChPpgbyXyMl6aHLIWYqEQ0LWcrUyqJ1zF7vAl2i7/4IIUHcJsbudJNNsG0EeYDBc5GmmxIR8NUe1OGCx2/PTCCn+0HhY+wlyEQQaT9iwIwW3y2fIMe/xuOwE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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 > 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