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 CC4E9CF9C6B for ; Tue, 24 Sep 2024 21:08:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3AA936B00A1; Tue, 24 Sep 2024 17:08:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 35A666B00A2; Tue, 24 Sep 2024 17:08:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FC256B00A7; Tue, 24 Sep 2024 17:08:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 019D36B00A1 for ; Tue, 24 Sep 2024 17:08:16 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id AEE99140414 for ; Tue, 24 Sep 2024 21:08:16 +0000 (UTC) X-FDA: 82600869792.18.937771C Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com [209.85.219.50]) by imf21.hostedemail.com (Postfix) with ESMTP id EEBE01C000E for ; Tue, 24 Sep 2024 21:08:14 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aw24xEJI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.50 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727212079; a=rsa-sha256; cv=none; b=rztBETbYJUZ8WNdd8eOI1h1kLhi3wDER708YXNx0jTD6EtL8xyIkKlN9xCPgZyOWil8OWD 3nwVrlx7kVA/kDXNcRR8moKXkCDv88jgG6ccMBLNrO/xvjPBQLgKmcUJXR9rbmbndxGF3r CppXz/NOJMX/Ld3TEfaHa+eMv8ob/ak= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aw24xEJI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.50 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727212079; 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=SSMnSNvjgL0HgXS96DbEez/+JL/Fq+TwXsk0eFSypFU=; b=W5io5TWMmMAO8WviFYZVLO0I762Yv/jQatyNF4sfUuQN3osWLMbAGKq6H9HNUBxyIyaVE5 vqL9QtvGcEodO5FuhfqkPLCqS+F6PjrIJhFlifJ+ywGamdwdwzMTSVr1MLEc+qzefAmO7n hx72NE4YRXNygJHy/+jWueYIxIY4NB0= Received: by mail-qv1-f50.google.com with SMTP id 6a1803df08f44-6c34dd6c1b4so42647196d6.1 for ; Tue, 24 Sep 2024 14:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727212094; x=1727816894; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=SSMnSNvjgL0HgXS96DbEez/+JL/Fq+TwXsk0eFSypFU=; b=aw24xEJIQEuilrL1HW9QMb/oPEN0UaGYkEpnX6emugRfCadS0oY3gzsV0oLq8vKhL3 YyveuVgG8U69qq+steub9wt8iImJ7clvSqoUCiFLNSRmn2Xf0hI7MaUQGrigtmjy7IBD se+Fh8E6YHkVwkScjNxdj1DkN14CuSZeWtJPCv/6aDtEimGAo+xzsG0EMTV8RCPhSHPD Y6L2BADnGkTIXdYWZ/AEOP1l71z3W+927FtjI/PodqabbdUzTGhtd4G2rhMifdDz8JiN /1Z2as46ny+7nkGKtGSambVRviQpxLcuAgL8gX3ioRjF93feVsoP0HKLYeUb24bM0qCD vttQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727212094; x=1727816894; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SSMnSNvjgL0HgXS96DbEez/+JL/Fq+TwXsk0eFSypFU=; b=V0eI1X0FyusTvRIMRCIMpY4RgPEHC4oQJCVbjX7jY0VGehe0IPhPT/nfIMFFbtWSEM udll+938YvEctfo1Qs9rhQWVR56MrK8VjLHlxl6lv4/8C7+AMMyNzMpWv1UG1Y68jxIo 1OMM8T/En573xIBI1j1tJydTadEEVRaPmW7EUIjfajGZsqJJM2EYhM39wKudeJn6aiZk 6kcVrApiFyicyyhMxjlYTtv5p1ZFp7+kx/fr/Y1X6SJZfGhcGU9JQZt4VYFvoyvVpCyP vNv49CnFv+DzgLhWBZuXlBiSDiam0V3rO4hQAdXdgKJ42usiOYJU4o6ZITpNVbtW/JpA UQwQ== X-Forwarded-Encrypted: i=1; AJvYcCU6DivcXu7++ekfTjaIGRMmpnVugFYio5CFw+JbbL1YPEXVl8ESiAhyTEec01+/z2xkcLcuisYveg==@kvack.org X-Gm-Message-State: AOJu0YxiiV7Uq9Q7bi8U8cXzKNIsrYY+92J+1hu4COXOlm/+/axAuMLf 3hxscBlnyTnriJvlN5goWjpLLyDz2IMHn38uS326L1WKazs0c1Cmwe59g7Ja//FQx9WcX+h0HR7 RZmPkG8uRg6b85Y0GaEerUScFoU4= X-Google-Smtp-Source: AGHT+IGCmA3qvUzok96RjQDT3EVBAau3Kny/vhALAySBV+fIqKJa/T0yPs6n3+jE90A8DTwCuoza26XdQx2gDjspogc= X-Received: by 2002:a05:6214:451e:b0:6c5:a2ca:38b7 with SMTP id 6a1803df08f44-6cb1ddb34bbmr5289676d6.27.1727212093984; Tue, 24 Sep 2024 14:08:13 -0700 (PDT) MIME-Version: 1.0 References: <20240924011709.7037-1-kanchana.p.sridhar@intel.com> <20240924011709.7037-7-kanchana.p.sridhar@intel.com> In-Reply-To: From: Nhat Pham Date: Tue, 24 Sep 2024 14:08:03 -0700 Message-ID: Subject: Re: [PATCH v7 6/8] mm: zswap: Support mTHP swapout in zswap_store(). To: "Sridhar, Kanchana P" Cc: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "hannes@cmpxchg.org" , "yosryahmed@google.com" , "chengming.zhou@linux.dev" , "usamaarif642@gmail.com" , "shakeel.butt@linux.dev" , "ryan.roberts@arm.com" , "Huang, Ying" , "21cnbao@gmail.com" <21cnbao@gmail.com>, "akpm@linux-foundation.org" , "Zou, Nanhai" , "Feghali, Wajdi K" , "Gopal, Vinodh" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: o64ojkisn7jcjgobf1wa9a1zjtymfwj3 X-Rspamd-Queue-Id: EEBE01C000E X-Rspamd-Server: rspam02 X-HE-Tag: 1727212094-527866 X-HE-Meta: U2FsdGVkX19dFmCvriy6AX4IyOo9nBt27/ZM4Da2hzFsQ4L3aUfl66DxaHj+nwllUGUeLMzb9cFfEqVhbdywl4BHbB5KJjT6Q3hmnjEwRaBA1r2VhSXxiJ1GrMRJCLBnJ39pS9rEEchRubsqxeiV6hBSFLe5LU/jXMjgPnNHook+kUd5riiJAwH8OiGvKgFLwfEtVLhvu5eiAUVa0z5XMfelyFBSTL87pII6WztlBa7+dXlOi1K6YJF2rvQJFe72d2c83z4LTlZf/fdU+dhQPjUctXCH40J5FXv+m5w28oWge3034kMVrgeC4QLKTfnzmQ3eoMlIGIVVP0TE3Udy9s74ZUGfJA+ntFEa8scGp6ojnMAFpBEZWOav/cDSFzknZ4zT5lsH5WeZzl659W6HmSRQMT/lTKh6mgyK8bAZ/lEUYlJccVRGVqCslLuZDkygbEwC3elUvxbMQ2WFrho6mpkd7XVsa+o9Nqjfi7yayPa3gtsBbIS03LUKJ9MwIYitEXiKRm/p1IMjYdpJ3SpVA/lsIHcEVI8zzGCROxIRAdo3aGmYtoJRD928zvSdYkr9765YviQWuoHvI7h8BS9N2E1535XSGA70qZLPjwkl5ZyKecrCCR/FQU1G97G9vvCnjMArcrPR1fLgXny4LbKaK63aonmM0gdUR063cAgu6bfopnhKUrw6qTOrQf5KAnw+0gD3SK/Mz4EOpw0p8ph8sgtpzLwi9psypVw57B0kpAuQlU8LAjtdnah2FcxHycZgO2NTNeBlfMuvuNM5rkDx9P25J5mtU9W4iMB6Z4RZZscrmyYVudN2yC3X1bbWBiep3JvgvShBQbPB61Svx1KvXTvG8xikDtjgwyDW332Yr/BWjsVFpiKhrZyvJvjeK/vytghvfeEjxDQ1XUQuzdRiqa05KZd3DlJrkiEeTjPCGIVgYI//ALvGnI4PHlxLb4HMfLK+Fwyc+iRQ/50d1PU ztNIU4T1 3yhs+gqtuFojSNhF8keStaBGb7bhGofJqYemNjDkQaWP/FQp/hdsX7JMB9UoOX/D/lhTUi3v3Ir8a6ma9GCs+IQDbRPdvaAusmkqUzHE7SfUUd73n2i/GiJJ9fEgBsEPKy99ZU9PpuyOE8mJV1i4rNEQYe2ZayuQiHP8DsK5sMF9Qz72CUK8W9ZvBsmyxYcrNR2B0NDteZakfHsPzidvp6m0sC87eGYHeQ0YqLoFYArJ49XtaxSfhAKfFxtxThvTOwKyzXcsNocNtktSDDmWHcqnDlqp07F1ngNusbi2zqNMbpW1ZzDiTI9+Vks75Tk831kujAq1beBK6zkZE6tWew9fW/XmRkQn+MG3Zc2yBKhWLA921zOMIrIBpP0xe3bq4jbFIbR0yQsIOwWU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.276718, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Sep 24, 2024 at 1:51=E2=80=AFPM Sridhar, Kanchana P wrote: > > > This is an excellent point. Thanks Nhat for catching this! I can see two > options to solving this: > > Option 1: If zswap_mthp_enabled is "false", delete all stored offsets > for the mTHP in zswap before exiting. This could race with writeback > (either one or more subpages could be written back before zswap_store > acquires the tree lock), however, I don't think it will cause data incons= istencies. > Any offsets for subpages not written back will be deleted from zswap, > zswap_store() will return false, and the backing swap device's subsequent > swapout will over-write the zswap write-back data. Could anything go wron= g > with this? I think this should be safe, albeit a bit awkward. At this point (zswap_store()), we should have the folio added to to swap cache, and locked. All the associated swap entries will point to this same (large) folio. Any concurrent zswap writeback attempt, even on a tail page, should get that folio when it calls __read_swap_cache_async(), and with page_allocated =3D=3D false, and should short circuit. So I don't think we will race with zswap_writeback(). Yosry, Chengming, Johannes, any thoughts? > > Option 2: Only provide a build config option, > CONFIG_ZSWAP_STORE_THP_DEFAULT_ON, that cannot be dynamically changed. This can be a last resort thing, if the above doesn't work. Not the end of the world, but not ideal :) > > Would appreciate suggestions on these, and other potential solutions. > > Thanks, > Kanchana