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 45DE9CEB2CD for ; Mon, 30 Sep 2024 23:29:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CEC0D6B0295; Mon, 30 Sep 2024 19:29:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C9BF26B0296; Mon, 30 Sep 2024 19:29:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B63746B0297; Mon, 30 Sep 2024 19:29:49 -0400 (EDT) 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 9920F6B0295 for ; Mon, 30 Sep 2024 19:29:49 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 025B6C0C08 for ; Mon, 30 Sep 2024 23:29:48 +0000 (UTC) X-FDA: 82622999298.11.C548384 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf18.hostedemail.com (Postfix) with ESMTP id 2817D1C0018 for ; Mon, 30 Sep 2024 23:29:46 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=dy9JZQ80; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.160.179 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=1727738847; 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=RVg3iqUyEVc42GO5p5mggpA2AYHoSPqXb5lX4xc8TZ0=; b=q4INtMi0+KXalk9/7MufwPJux8aIpO9ZWckGDdhuJE7kDeEaQh7GEfysxNkC6fRbqKhMTd 9grJHe1f5d0D71g1Y20dnBR8BvGC/COXmF3Bp+NZ1lPUoJPyJaE0EopqBE4p1m+iQdyCP4 7VBe9Npherx+gK0Kpk5RMT6rB25SEmY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727738847; a=rsa-sha256; cv=none; b=sAALPf556TNCftxBpry+9/HslviNR217+g+5njRRyuAUN04WBKS/ZlNATwlxIo8VnzpNuY JDw5iqdpBXfSlgP0sQKd0Cz8KGqwhOE4HGxJn04PUo6k5D5jFNBewU/4LfVl0JNeEdGnFw R2PG8yw43ZonXJjMzn146xaKTxL0Ayk= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=dy9JZQ80; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=nphamcs@gmail.com Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-45cac3368f0so17083051cf.0 for ; Mon, 30 Sep 2024 16:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727738986; x=1728343786; 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=RVg3iqUyEVc42GO5p5mggpA2AYHoSPqXb5lX4xc8TZ0=; b=dy9JZQ80h+7aZraM8m2Y4hIGsN2I1wUbcUinCrcjkAEp8lgSOGpQ73RyzPOHvQ/e0g JygDs8PNdrTaDRTD+1xYslbZe8LSVXi1afksJJlbU0Bw8ImiznpHHIclyf/L/tfn3YoU m6HzMxjBRES/2M7B85tFNOQ7OO/r3O0RIDo+k2BVKke5K70L8ob95lw5jwHK3aJb3Y/Z +tkz5hX26H8Duqr+pzsXVB6URhJ3jGk4R3eITGPg5kSdFFMXKflD7VnaQ0Q0LHl2M+lB tPGe62u85AQEj0upLaPQonKRrC2YbDsG3XT7nd30kgkAutV0s9XOTUkjTG7+VhdTGAuO LcQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727738986; x=1728343786; 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=RVg3iqUyEVc42GO5p5mggpA2AYHoSPqXb5lX4xc8TZ0=; b=Dqy1+iY4rssKXnC0CHgbSmWQlS2yflhiJr820DEQv+NDp7lEqpIaGcw2xEXXJ5rSMV MC7d/f21bPf+WH/X4XP5r07sl3EVbZxM4owicWMWkVxdxQqN+cuu6Whl0zm0FIOoq5O8 tQWgmnjZRevsMPhg/0dEkSQqKpbS72CXLvdk5oiB3/0uHhQZQ14IWxRT/HCFmCtA535G ZWE78B1zUpHkB/+LOLkq28BvoWkeeh/XgD83u2TVLXvTC+8Ro61hiJ+NvJp6yqq8v4A0 MzDQVSlnJRcPAjbnrgu+5fbYgYKM18DsojzdKhzr8AlAI0ybW68WYDKkSqe0n3msN1H+ VeZQ== X-Forwarded-Encrypted: i=1; AJvYcCXMsqGOmShCKXoOjNPNnyc9PZRNnnkslDaQNbkJsZwuuuA4hQasDDKDOy5JdMK3iuj0aQ9k5uEOYw==@kvack.org X-Gm-Message-State: AOJu0YwEKjDPwZiDr0ul0pfE8ex2+ZExJmu84M+pPglVqAify8RqY56y mLrCKu2XZX2ZXGf5VW9k4V6ucGDgdC1AhzCgXarThHLagorATiXnoHPlk0gGYvqBh8SwjaVVnx3 wXaSvRhbZT7yEsPjEVNgWBbhBb/9NdMj7 X-Google-Smtp-Source: AGHT+IGvWFD/0j7RApmHvPmT3hQD1pg2b4JXNfPkXBacgAnRfdPOJWcs8hnwNSl+TkmsuHU3eRYKBglUMBhmvQrk+VE= X-Received: by 2002:a05:6214:5b83:b0:6cb:4713:9df4 with SMTP id 6a1803df08f44-6cb47139f3cmr163529086d6.4.1727738986139; Mon, 30 Sep 2024 16:29:46 -0700 (PDT) MIME-Version: 1.0 References: <20240930221221.6981-1-kanchana.p.sridhar@intel.com> <20240930221221.6981-7-kanchana.p.sridhar@intel.com> In-Reply-To: From: Nhat Pham Date: Mon, 30 Sep 2024 16:29:35 -0700 Message-ID: Subject: Re: [PATCH v9 6/7] mm: zswap: Support large folios in zswap_store(). To: Yosry Ahmed Cc: Kanchana P Sridhar , 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, ying.huang@intel.com, 21cnbao@gmail.com, akpm@linux-foundation.org, willy@infradead.org, nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 2817D1C0018 X-Stat-Signature: j7run7wzqz74m4t1aobb1ty8ty9isift X-Rspam-User: X-HE-Tag: 1727738986-937477 X-HE-Meta: U2FsdGVkX18U1uAqb4EnQ1S2nDZmAcHXTEivFcJ4Ru/jxlFcLmPEeLBoimamx16y4ECndUvCrJ+cz3V6/RaVrfHRm+GAPKWlsm9hncJryynx/cbtvJoBtPVO7+DpToFhqSftIRsBdR7gaEy5OFaOeBb2Pg99Xpu6xPWIbRA+B7A+4LMaU5l/3U49ar9Kd4SoOnfcRpsPIrsajxIRbUBlSzepqwkR3vhi03ZXyKp73lXuP8N3kuwBrEpvfAqbIzIFULpEQG78T8j8EufWkc3wZYf0HJrHs3yuuxXbFxCrQUFbe4OqwzuFE1FRTedqphjZLtY8Yp+B4fEKLjTmGTjDn19KPjDo8xrRCLeMxb/K2KxbfY8ZDuAlmfoaCU/z3ftkAHrR6GZOg5nCq4vs0hYmjYtCjdHrcrL1RvpuRxJgHkHjjOmkdCxVflDGn07zeZF3C99IVU8SArhwHfY8OdcFoSd4ItCnqKTh0bHa1Nl7AiLEIOI2M/ntAkUZD5geLyG2sPAOSOKbIf3X1bd/fKtKVce8s7yqReW1bt71nrF85GMjy/FRz4i7dlV/yPCQC8zQlVOX1jPou+yv4tVg1DUzk3U3W5F+DYkZ653K21w8Q0deNh90r0GUViizkZbhpiN/s969cRAvgnWuZe5Xf2BaQOO/3btQQDL0UziLCrUB9ZxZcnJeTEKivFwxtq0UheJzV5PinABkklo0U8paBZxj9uUWTqh2SPmB6/ZLx0JojzTP/zAFIxfiMMqqgfVrbaxUSIsZabiSrczab9R1RLK7BIK1veWS/HQL+JXzgumLEEFtDRlLyfY5Ir9w0OrenpHmB3q+3YWt2MLr1a/6Yst4j9Dy2dUCm2NE83/Lo56X8rb5uZ7uzIFReAgbpuC7FYC/n2dStywweHb+Q4n1BI+NDIfTT7EVgxmzUIEs7icV5w5rtn/mIHfTW3MLsz5tV2ZROfhqqM3qM8VpBXWvRTG T1G/6A/P LVjDZtWGnHYMBSoxDXgJjO15ZkVf2fmV8sDIPd2ygWXZp6WQLAsoSayn8l+TYqOlHDzbhMMSy3qC+a0viabbdVVVGWPmSQp8uxXGq6bEVe6ljFtGMzxb+a3CfpWDXwgW5fdU8Y4BHUlfIaptiYO8YQnhyALl/r72dCOKe0X/9jd5wcxTIaO7ncdhjCaY3zfU+J21LWLn5CwpETemofn7oZzKJKnGCVBrRvZbnchtm6IDW0Mt89Xe5GqO3gVInCrnrlbXy+C/KM9vCdE6x5TF5Hmp57SiueTvJrRDRHkL2NohIVC5XrdEwQkAWdX/t3ZTCT3Ml6tCeb4xk8oym05eLwfkX4oTx5VPA70nGJCIgiKCRLHQU9xuktt8kjL9k4nyL4ctyKn2TZRXmopV0tQRqRNge4ZjFKS5hO8PP8RVIlNK5N91kMSIzQait85QaeZ+OwUKt4BaIsHH51g4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.085031, 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 Mon, Sep 30, 2024 at 4:20=E2=80=AFPM Yosry Ahmed = wrote: > > On Mon, Sep 30, 2024 at 4:11=E2=80=AFPM Nhat Pham wro= te: > > I suggested this in a previous version, and Kanchana faced some > complexities implementing it: > https://lore.kernel.org/lkml/SJ0PR11MB56785027ED6FCF673A84CEE6C96A2@SJ0PR= 11MB5678.namprd11.prod.outlook.com/ Sorry, I missed that conversation. > > Basically, if we batch get the refs after the store I think it's not > safe, because once an entry is published to writeback it can be > written back and freed, and a ref that we never acquired would be > dropped. Hmmm. I don't think writeback could touch any individual subpage just yet, = no? Before doing any work, zswap writeback would attempt to add the subpage to the swap cache (via __read_swap_cache_async()). However, all subpage will have already been added to swap cache, and point to the (large) folio. So zswap_writeback_entry() should short circuit here (the if (!page_allocated) case). > > Getting refs before the store would work, but then if the store fails > at an arbitrary page, we need to only drop refs on the pool for pages > that were not added to the tree, as the cleanup loop with > zswap_entry_free() at the end of zswap_store() will drop the ref for > those that were added to the tree. > > We agreed to (potentially) do the batching for refcounts as a followup. But yeah no biggie. Not a dealbreaker for me tbh. I thought it was a quick change (hence the fixlet suggestion), but if not then let's do it as a follow-up.