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 6F416CF9C69 for ; Tue, 24 Sep 2024 21:35:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A78876B00A4; Tue, 24 Sep 2024 17:34:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A29056B00A6; Tue, 24 Sep 2024 17:34:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C9046B00A7; Tue, 24 Sep 2024 17:34:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 6CBE46B00A4 for ; Tue, 24 Sep 2024 17:34:59 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D573314045C for ; Tue, 24 Sep 2024 21:34:58 +0000 (UTC) X-FDA: 82600937076.14.6B7371F Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf18.hostedemail.com (Postfix) with ESMTP id F090D1C0010 for ; Tue, 24 Sep 2024 21:34:56 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=CZWIZmJx; spf=pass (imf18.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727213636; a=rsa-sha256; cv=none; b=g/hZwMaNZL+GR8WK7CfCaNUZRqTHhNXDn46wAGYS+kJW0zI6rSSNFCGJehBJCD3SOB3TBZ AzeqtS4k7RYvTbVL32Po68g3/8+vYI+p/QnCXhE1SCneZFzyiLe9ccQdh09eIepUfvtEiU mdU9nO1cVrAWWQYW2M9c9ovUW2xB0/0= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=CZWIZmJx; spf=pass (imf18.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727213636; 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=Ihhqm8m5Qh/kMpRgCqE3tbP5xFH8qdU26SE9syYFc2A=; b=t4kfOgSxe3aj1DQOk/UCEdZ09DL1zx7o6EyDKQuqiSrKdGbVue5si+LBc3E38RdUKNa7zi H9SgA36txmykReVUxHUwNHWiu+WDt6RVH0h8gtlOw1sVmhDtYrM1oVty1KzADxN5RMa76A 5q+0qhsrmuq3IJj1Qgp7Rzhr5fFeCPo= Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-a83562f9be9so709187566b.0 for ; Tue, 24 Sep 2024 14:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1727213695; x=1727818495; 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=Ihhqm8m5Qh/kMpRgCqE3tbP5xFH8qdU26SE9syYFc2A=; b=CZWIZmJxewuJeJfK4v0NqA+ChIx0VzkJ3iIs0uy5UyFYHB/+yG7wEoLs7hBr0Dz4U+ zalxkavj3pKZqKOdw/rb3s7ahArM3hNF2ppgnlxdyTb0/VLmYwLofs+Wb/YBJqHzFg0x pOUWm5sCcuqZOGOigrkFug/nRTL6HD/uEfZvFst+p+FJTBdcMB3qcq30lmjjftjBN4of VDmGmKckeNqR9dgXoPR9jiKS7ZP3cp+7Od2oSsA1Y1QHwzc0cmEhAlkIotpQVYqOFKRc DwhKxxf72n/p8HJ1prxqWfCR4b2jj8DUkPqRBrEeEId9LhmyaPDY9ahhwfSZuvqL8y1D v3NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727213695; x=1727818495; 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=Ihhqm8m5Qh/kMpRgCqE3tbP5xFH8qdU26SE9syYFc2A=; b=GHgxuWKjUp2BKlcdnTs1S9OAXR+DuXGT62SmxwTHJvzHaLcmW84y1Ej+LyM+B4PoYO H4RIHnVNyJb9nYaJRRdh+/YrUXkInsiprW7MvxfCr/qlqPqWwWBmTthzsY/+4Ed3R93P 1WIOuz8AGA6ZH7H9Xlz5jQvFoMOK4vTU0Z+/tvIUMq/+neUlsJYPGZVC116R1ivMQKgR 5Zjv0QrFSx4onoUdMSil8K7JzlAfV0i2wG2nRdzjLeT7dnt4FLsVNLHFWWU8aJdwpakH +9eSz6pW/Izc7PyELKO4Qz22bhUn65I9yYWhG3jOmrlqVpBjpnU4HuL+G0f4VawF/Grp PfDg== X-Forwarded-Encrypted: i=1; AJvYcCU5ZsB4FW0jMs7khR3bBzXXJdZRHXNcwlNGu6byLxKggKo0iG8zfwFO3nzHysLCjdKqrJTHF9UG+w==@kvack.org X-Gm-Message-State: AOJu0Yx1rqiHSUVypBeAc5EUtDgnYlRES6+/xoYXg3UWAR8Hrdxtu4NS 16YzSpB0djjuRMWeogUzePnyKmt11ZVwjRsKTdavpzsb7B3kLUpeUAcjsgbGWztGXDZlQOR+Pku sW/DsX8969gnrLNy2veMk4wucrcDnLTtCZdie X-Google-Smtp-Source: AGHT+IFGjImsKTq8f4NzlhA/wTzA9/r023kIBe/p8GR8g/F0krWD4o68iWS1PDRX+N2NPRHUxMgS4wne5FmDfDOExdE= X-Received: by 2002:a17:907:1ca7:b0:a86:7cac:f871 with SMTP id a640c23a62f3a-a93a06b5943mr52905366b.54.1727213695314; Tue, 24 Sep 2024 14:34:55 -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: Yosry Ahmed Date: Tue, 24 Sep 2024 14:34:19 -0700 Message-ID: Subject: Re: [PATCH v7 6/8] mm: zswap: Support mTHP swapout in zswap_store(). To: Nhat Pham Cc: "Sridhar, Kanchana P" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "hannes@cmpxchg.org" , "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-Stat-Signature: fsomn36eg9inou7d8fnwqsz6ybn8bs44 X-Rspamd-Queue-Id: F090D1C0010 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1727213696-444449 X-HE-Meta: U2FsdGVkX1/6u7Mt7LWFIi6qe0jVHl8uGtySycxJj3Oac5WoGZa6pv1/XeP9AtvlCMdEDjsYgiDK+gOKsnoGrIKht80HH9Z1rfbUl8IzBP2s0G9tRCHcmUFFH627tftbvlM4apLWeoltcnpSK6ztKXcfDby4xqW8voeZ/IEGkKD+trIBqGhMhG+lcQqgcSzuAUh6XEi2WAJ4ErSgeD+2oHfTtv6GHBZTWFqdLeg5Wh5i8bp9N1NhcnuIKmWAGd9z6qREbaiqE7IK26TifWBgPgNFYp1+AmMY4Rt1IL1YHHCR6eDS78xrdDn3Om8s1NDtYxFBi1PNjsnTkIUmEMKc4fpHWZ2ibKoRLE31kTxqjG7oNqYTMFLEocKj3qYn39phKqw66ZNYgH8WiLZ68jsgczZtX3KGIpseve2IIXYhU6OACh2NejYYyqJKmuKc83vhq4CrAwu+TkvwAje0etKurwKsw/bVzxyTc9b6ZBxzG5nNKQhrIkLD7zqgYndrMlpcq9pZwLB7YzbZX3rX0iAuwg8XN7Udw8fd5igiHl/cRQfopS+j5pdrL0zU8tBz1VhW6eu2IUToD/ElMqW1tMZkVT5rpQnbdn/oCiZGPUrl5bf1mnkdIyaWirK98L3zP1TNJKdwPu44e+XnEY81BKEcqBf0mGF7UQxPeiuqT+eUTfalwbvHKwYjL1XbIHN4f/m9SYwOC3FXz06KcXMmKqFpPOUpyr3byKuWcC9bMNeqpThhhXMzwKcnOuSc+v4nGLBkHEHqZvDV4K6S9XZb7JvTiQ2ffEge6wXDIuaFR+QZ+rqZnL7K267n1fTdc+iiMk41k6B3mwsxHPtVATPdOK2yw/DpHCTZYZuFi2D8czZ+K5FfZ2ohRahgAfFsWWYL7T1c9dSF3YI/O1+SNRdzZQrStpsyCjJWFCtMioer6F3KeRGq7d9lQYjE07ApwXhiw+Nl0+ieRoYWH/3HxMHuHOu piUt5kfi Ndncc9+uO+hHViM7bjzT3yZiQhoQod8OpMlG/y298ZztPAK2sByCf6PuzTh0FYKtLAwupuqKJ3VlXLl+oVgKx5iUNXCFbyAmYSvIjqzsCUYfKyvLZlhddXes8xq9zrmdiTy9agibD0UTFtCWDvTEhwHCCz3TtAb/DhFikF/Ar+STYkvUueJxWdMB8dDVxSssvTHbE+tp0OELH3xIS5BQ79pVM+afAyFNBVzIiVlYzBQRUOGnldbEPELovszvxL0bc2ypCsVIXuZWXre9PDgs8OI2Gr3N0Vjo8oycjQsVdi+Igx4/+Cv1hwFNySph9luuPjVz25TT2mwpPfOY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.104611, 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 2:08=E2=80=AFPM Nhat Pham wrote= : > > 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 tw= o > > 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 inco= nsistencies. > > Any offsets for subpages not written back will be deleted from zswap, > > zswap_store() will return false, and the backing swap device's subseque= nt > > swapout will over-write the zswap write-back data. Could anything go wr= ong > > 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? Why can't we just handle it the same way as we handle zswap disablement? If it is disabled, we invalidate any old entries for the offsets and return false to swapout to disk. Taking a step back, why do we need the runtime knob and config option? Are there cases where we think zswapout of mTHPs will perform badly, or is it just due to lack of confidence in the feature? > > > > > 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