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 43284C27C65 for ; Tue, 11 Jun 2024 18:53:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B45776B00C1; Tue, 11 Jun 2024 14:53:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ACDC26B00C4; Tue, 11 Jun 2024 14:53:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9477F6B00C6; Tue, 11 Jun 2024 14:53:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 703786B00C1 for ; Tue, 11 Jun 2024 14:53:25 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1D18C1C23B9 for ; Tue, 11 Jun 2024 18:53:25 +0000 (UTC) X-FDA: 82219505970.01.675FE4A Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) by imf11.hostedemail.com (Postfix) with ESMTP id 62FE340011 for ; Tue, 11 Jun 2024 18:53:23 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=W1ZkYPU1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.52 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=1718132003; 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=QgNfDPKWx5weTgzZ7sQXsFLCPiSrq5i1++lcPqyQBGw=; b=MKvOZncPvw8opo7nzo3rV5hRni19q6jBLz4LDt3I1t2U1paJXnNAQj+NrSP2O8XD4G4o1s rSAOY+eGFvKxuzPgR/ZZCSZnQBkO6yhtgTikLd8BRNyQ0nWDwhrkm6T+FdJRHo+qJW3GRO TrJjO3Hc+hUbO23nPvCtcK4ayNNsLsI= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=W1ZkYPU1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.52 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718132003; a=rsa-sha256; cv=none; b=cmwSYMXdUfCFohJG/r/ww/dbuymloOiTvvURZkRJfuiDjSkiJpw4BvMrBoUtp9u8qXuXyl j3KlZxKvl+k1UpCJCxRDzDGkM+dm9QmZW9E4GRSouNYFW83nalwcURMnaSz/LanioRLE22 9GjnC+e/YeMQClxowfDaLiLpIgoc4j0= Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-6b0652ece5dso6686996d6.2 for ; Tue, 11 Jun 2024 11:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718132002; x=1718736802; 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=QgNfDPKWx5weTgzZ7sQXsFLCPiSrq5i1++lcPqyQBGw=; b=W1ZkYPU1X4f3zliknsjYuJ3uw6ZCiTsN/K1PzvL4Lt6N+Xe6VQ+ZwTbSlVQ2LXWJuq a9sVwPV13UmDCc2lvRofWsXPheituPsDLnnNqgF3l0EdXT3fMs7lWrY4MMcuwZypMcj4 nmxokaU/6m3eANdiE662sai/Wal1ouXxqoaKp0S52DrvVwVbanOhkxTiZdZ9Tr0mED2I gEwUN7zIm3rV/PszV4Lnwqvb13LeBAyPcnhO5Dk5l7WrW6wjVgjPCN33I3zLLuXc2hWL d84m5c5axV6fmKjbOn7xSESTgiVJyBd+j6Vjr5TEOH0yxRUEsUjOlhfVSMkQBa8S9DC1 ZiMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718132002; x=1718736802; 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=QgNfDPKWx5weTgzZ7sQXsFLCPiSrq5i1++lcPqyQBGw=; b=QgOOl93W4H2pMoHiLn8mkw6FM+Pc+QMdEHJUIJWax25I6bj295AFOrMEo81Gq6/vWo UXgPF9BVJdA2g/W9VarE12lTxlrRlYloL3K8V+brTfpn0SENE1RN/rkiQyM07LIhKi+b sU/i4iTWjbh21Ti0ZVb3DxFXiUMx6KQfLftHzHqjVX+jH22zCLsl9AKTDF7XwoNSN+5T Fh44/cDWbxrPaIUU9oB9LUXXkE+zzwyL6sFGIiz6+SSIa2I/s4DrmKFRATZ6QByLec31 uF57768n1LhMC/WuZ/PMLef+UbVwCVJTz0wrLO7G1ng7s2bsx/vJ6ZkYUUetd8RkyTmS iFTw== X-Forwarded-Encrypted: i=1; AJvYcCVzPlYXJSeCB5r7ZyzkSMNJsJP1nBOZry/fT1kU06KL6mBKDfLQWEoegmbFd010kEghvS7aB91i4Em1xdMLxQlAzv0= X-Gm-Message-State: AOJu0YxJL3zaFtFk8XhcXj0lY2vLYDt5Tk1gGzBdOcb9F1zcGy+Y+wGa ACmH0ZXZMPLHUIz7N5IwXLzugPD8NfKwDJve1htp7iWsddQooCudew8zLI0lgHz6tAIxO+z9Xs3 4aa1rwDJZMQCrXv//M5DBDVQeybg= X-Google-Smtp-Source: AGHT+IFUZEuzSLrNmU7NYyDINsrLctk7Nvg33ipU/SYmAdYZwIr71Ng1tnpFJiC44maTjzmE3Un6zcawgGpLoULGG7M= X-Received: by 2002:a0c:e7c7:0:b0:6b0:6478:ca8d with SMTP id 6a1803df08f44-6b06478cc19mr112256506d6.39.1718132002415; Tue, 11 Jun 2024 11:53:22 -0700 (PDT) MIME-Version: 1.0 References: <20240610121820.328876-1-usamaarif642@gmail.com> <20240610121820.328876-2-usamaarif642@gmail.com> In-Reply-To: From: Nhat Pham Date: Tue, 11 Jun 2024 11:53:11 -0700 Message-ID: Subject: Re: [PATCH v3 1/2] mm: store zero pages to be swapped out in a bitmap To: Yosry Ahmed Cc: Usama Arif , akpm@linux-foundation.org, hannes@cmpxchg.org, david@redhat.com, ying.huang@intel.com, hughd@google.com, willy@infradead.org, chengming.zhou@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 62FE340011 X-Rspamd-Server: rspam10 X-Rspam-User: X-Stat-Signature: wecm8y8qtm6kpxx4qym333phff7xn5bc X-HE-Tag: 1718132003-234733 X-HE-Meta: U2FsdGVkX1+Qmzvwv7eMd23Xqn618DzbLDYMt8FMp5k2K/9p4Hb/jXxcbms+w8jUcEV4df6XWMA0Dc+oUkZHA10/ErylMOjRRUfydMEwDgf3ABMTr1fdiGKpqipYvloMr4k2jH01zVsWd4zHhX7TMX+m2WAQ16w7cWFT1BjD2VtqVJ/kCjQa26ys62ZlYT4H8Wke8t8cPsQFiu7/yZPY02pRs5KXdtIEm2h4S7gRu6bq6xYmtACJPxTpnLMJb2IUr/rDSILsIHfX2kAPrRigYjz+AoFp6DbBwBBpog1towLn3X+hK068kflaB5tbFoc2NU8HzTKhf5yi8bTISK6qaAyk7FuxUvN+KxWUzCHnfSNzl702PPSlMho5bnX8jBxsi9vdvwDyvRzBx7T87r+zG6p0Vf2hQ5jOrWMeWUXGotHQtNlyaUNnQeIi3ZIiH6jUZFs4EEl96OROLD28tGa4o46FmR/P5HH+OB8OQJ12d4KHthMutL2vuPx9Lhu7IA6JzPH2XY3XmvkhF4rAqvxv9NP7ZSD4LuPoKn7UFmXxjzVmiXfv/M8OhP3paKS62FtFfqsmX65dZtV9YMKW4va9h8lCDjJWn5utmwMxfESHAVosdcFmtoXfFTYMXpaW8CxuQXIxUefL+2uZN0fQP65eLzDtFGSLwf9gliVjngKPa+0vpbZtV1+uOgZ7KPzHDDN0u/hOf/lzb2hbGRGAP6/pkWoTCoJ2R3GXWz395nYNoxsLLGo1KGa+HmQIxGvlP8ik5nt48ZUOSOZGbvMOGc9LmBjKG4PCQI1GvADOmVjmnUtyCM93pPSjz5Jc8i7qW0ceLK0ZZNw7M3EHJBLwQyY6mVrcnmcxoJtOBeuE/TIEXKOP9tPT8YfMHf116ET4Lk7HqsWPo9EyHme+1uRVijJurXwhKQzrefr2S9IEhEH8zeinN9ulXC/jFGYSGdCYpvPrXMA4vaVGHXq32pPmzsX mIRtHZz+ i7C4nl7h/aUtFJtjYsvqfp/ihH6ajAT0v7nC/P1apTosKWMlakEWfL2Rmq/Cck+8q1IYmXmlb64Vo31jAugle8IaTq6Sdswh/Tn4G7yB+Dlrv2+wUzIdZR0xBG4u1eDfV0HA5B13LBggKSIMIkDJGLHMUIgfINirGWLucBH8NuWX6airuUJT1eoxpJKi7XLAMzWqgmowmTXMm+LEG12e+L+nd6nczdtAWJ1A9haH+6X+zN4t/9mof0mie1OuJGHne1adAWePKUJQ8pZAyXCe8imuTU3ucSZCIUXm4 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: On Tue, Jun 11, 2024 at 11:47=E2=80=AFAM Yosry Ahmed wrote: > > [..] > > > @@ -1336,6 +1347,7 @@ static void swap_entry_free(struct swap_info_st= ruct *p, swp_entry_t entry) > > > count =3D p->swap_map[offset]; > > > VM_BUG_ON(count !=3D SWAP_HAS_CACHE); > > > p->swap_map[offset] =3D 0; > > > + clear_bit(offset, p->zeromap); > > > > Hmm so clear_bit() is done at the swap_entry_free() point. I wonder if > > we can have a problem, where: > > > > 1. The swap entry has its zeromap bit set, and is freed to the swap > > slot cache (free_swap_slot() in mm/swap_slots.c). For instance, it is > > reclaimed from the swap cache, and all the processes referring to it > > are terminated, which decrements the swap count to 0 (swap_free() -> > > __swap_entry_free() -> free_swap_slots()) > > > > 2. The swap slot is then re-used in swap space allocation > > (add_to_swap()) - its zeromap bit is never cleared. > > I do not think this can happen before swap_entry_free() is called. > Note that when a swap entry is freed to the swap slot cache in > free_swap_slot(), it is added to cache->slots_ret, not cache->slots. > The former are swap entries cached to be later freed using > swap_entry_free(). Ahhh I see. Good point. Then yeah this should be safe from this POV. > > > > > 3. swap_writepage() writes that non-zero page to swap > > > > 4. swap_read_folio() checks the bitmap, sees that the zeromap bit for > > the entry is set, so populates a zero page for it. > > > > zswap in the past has to carefully invalidate these leftover entries > > quite carefully. Chengming then move the invalidation point to > > free_swap_slot(), massively simplifying the logic. > > I think the main benefit of moving the invalidation point was avoiding > leaving the compressed page in zswap until swap_entry_free() is > called, which will happen only when the swap slot caches are drained. > This is true. In this case yeah there's probably not much difference between clearing the bit here vs in swap_entry_free(). > > > > I wonder if we need to do the same here?