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 04EBBC27C65 for ; Tue, 11 Jun 2024 18:47:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6AE886B00A8; Tue, 11 Jun 2024 14:47:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 636276B00B2; Tue, 11 Jun 2024 14:47:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4AFAC6B00B4; Tue, 11 Jun 2024 14:47:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 2AFDA6B00A8 for ; Tue, 11 Jun 2024 14:47:39 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EA77E160FD3 for ; Tue, 11 Jun 2024 18:47:38 +0000 (UTC) X-FDA: 82219491396.27.E1011CC Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by imf28.hostedemail.com (Postfix) with ESMTP id 30548C0017 for ; Tue, 11 Jun 2024 18:47:36 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3lbZeS8C; spf=pass (imf28.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.54 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=1718131657; a=rsa-sha256; cv=none; b=ii+f7L+mfBKWLQGqU+J6taxCchRp9xqKriiIxhyek43SnpfC1e8AfFOzVe9Z3XTuxQZGAr FON9AOlLG2TseBYPHWKJ691+3KaU3HrqiVn/jG3tEzsXUbed11eZ6vXuLdx7MzAOSLzTfX IDxg+pxQ+bB+mnEt/U6sMskUeHDpdno= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3lbZeS8C; spf=pass (imf28.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.54 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=1718131657; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=JNeYgHGOcCIEUgcCulHv8MogYMF1pawsllmpPlBDkvY=; b=YeGXh1ZEfsCfZQOzyifxmI+dhQhBJOeVHUDynQNrrRqPGldT3iRMi+xQhUeAkuIZc3ZWZX KqoEvFWkmUmPkRTvKHWLIc61ZSf6J2HU/Hfih692fGoMJKXWrD7LyUxZtQHuFR9yUyXmkm dBEvDHFUcdntjWrtwfHgCZDu3oaqCNE= Received: by mail-ej1-f54.google.com with SMTP id a640c23a62f3a-a62ef52e837so740743066b.3 for ; Tue, 11 Jun 2024 11:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1718131656; x=1718736456; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JNeYgHGOcCIEUgcCulHv8MogYMF1pawsllmpPlBDkvY=; b=3lbZeS8CGrNntTxpvHODaRemy5vF+A0j3+MYwi9eVWgclqoG9LeiL1sKbaautY4Pu+ d8jRcYYPHDrpCXKgrr0SH3yQrUYt+mJPwBrM6F0J9ToowZMGBhE7VNd2Y37h5OYvlCXY /4ihPzYmuS6x7IuYtNEdZj29vPEtZEFpmLYElbKZM0v2d6dt21n4wyf2r5UmmYR/XXmp aAjWobXhDIf9H0H2Sj7W+Td4eK6c5Cj+G5i+PCgZImf0egIWqoNgq9ZWmvbDCskqiNuN l4ZsYDGZVrcLjreGRfvSa0XMEinq716TVOLh6mNW78IqHEvpPnoB17WXAA1WOtcqWw/z QBIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718131656; x=1718736456; h=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=JNeYgHGOcCIEUgcCulHv8MogYMF1pawsllmpPlBDkvY=; b=rTgxIdagl58HP+N66igggnJj+AOqgbLzlp9oqWxvWLAP8QPhouGp48kRSO2PJDM4Gi oqlRdn6JaXv4cpzQ3gHdsYD1ZYVxZId9q4Emt/yXGQ+FJm8wRnFtPuXNPmIo2a+que1z qXTtD9a+p/JycPE4cNnkv7zShOZMU58FICAcJqUghoY3xvKCxijb0RY1w31osSOrcfGm 7l+v5czUuwYd415GhsArawU6i9GVj0/xqKCI/YVV3lnLmeW9YzKfvfGvBg82W2WsqIV6 XXwZIVKTdYLLWvBelYaEqLJZvB6ZV0xJCjPv3Vsy2GW+gfc4p6Aoo+9rAyv8x+2LX2J+ YmgA== X-Forwarded-Encrypted: i=1; AJvYcCWnkMBqEnb6bo9CLzjjkkjFoaQHiK3Ayd5/O4NwA3GD2Od5sX0CBISwrMh3QJOOO53jGpbKMPoMV1DD7yo7x3cmf/M= X-Gm-Message-State: AOJu0YyeiBSkMrCCcqnp4+rp0+LNtcrLNAE21nuJbcoahgmB/sKfOYgL XvR5pXa0zpSnc6/6rpZVVYktgugfrjpDPuOjBrl/nvgA7gEqWiE4ws2O6YuV8v3WUE2OF+wBDeW txqLDim5tNOZMt+eRdJVdRP65L56N9uMo9SKV X-Google-Smtp-Source: AGHT+IHNoz6xrivvG2mtwG02p42fYi6bLD6cDom6BDtt8rlcH6ypU0fOpoYNCG82KwChYvI000hS+u624px6T+v4VyM= X-Received: by 2002:a17:906:a082:b0:a59:dd90:baeb with SMTP id a640c23a62f3a-a6cdb6d16demr818238766b.48.1718131655412; Tue, 11 Jun 2024 11:47:35 -0700 (PDT) MIME-Version: 1.0 References: <20240610121820.328876-1-usamaarif642@gmail.com> <20240610121820.328876-2-usamaarif642@gmail.com> In-Reply-To: From: Yosry Ahmed Date: Tue, 11 Jun 2024 11:46:56 -0700 Message-ID: Subject: Re: [PATCH v3 1/2] mm: store zero pages to be swapped out in a bitmap To: Nhat Pham 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" X-Stat-Signature: e6msbd6gd44f3itso8c34xyujcq17c8a X-Rspamd-Queue-Id: 30548C0017 X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1718131656-411703 X-HE-Meta: U2FsdGVkX19Lx51feXn5M7qB3dbLmNYgw75vx3SdbfPXDETykaSGX3wGfzoZ95Cee6soP0e4CSrDANF/ph4iaocprhZ1o/a63AXpI6vcIDY6Hx61EbDOyyVGp6IYQ5i1bLqzMpPHsFYWn6m0/63Iek5rmZg+tcmBvO48pRA4kfO79rqwEk2JDqoOv9jBcPYaebeGeoBA/S1oD8rSu5wzvGAn0yzaFJbGJLIIRqoOcYD4zdLNWhFsGzYHM6PQzLRvmnUk5jzoYvSQY4mNb3C5zbnLPkdYUj6hNB0fbj4HEv6JmiNS0RAry3sbkwX00We3oTncb2HK4KIIHT8MK1FGJsH9TJcE5kVIxsY6UMySeHMbOwIAFoF452ahLH2r5ku53wFJrlBFnHQJmJQGPsIJNF5T99H8IzLnCGu0bGYLmepRUx2sSZUsO+bvPKFtLMSQk9vnVJgg3mOAwmky0mVXrTdGj/pJYO5ICrfDw07FwSN1yTca0DrxQOoD20ocFJrxaw9nsomGG7Vj5oTsu6RRZ2pa0Nudpzq9vxkC5qelFwukeENJXNd6zU8hdRvoH5MGl+KDoQqtcHqveUPsYCTHGlxPoZHe8isC2yjsfQolQzziRJ3hWGVTQWRD6CoID55zO3vTRvt7+8RQnYZnyQb61n1YcFqBX0o3pnqNU8TdJ3HuCOM2ZS7JXYiFw45fVntQxQyssJQuWUHtl/ukqVii1osXCUGzD3/sKvj2I5hPBSNYY0M2bVvWTv3oX0Saaw9TWdVIm769O2T+VnVG52mfA5YFI6pfzu6ANuIlMuDQbNlIs221joCijzH21QBiCyVFP6MFvVRLFGATlXUIlt/NjCMh9vrij8cLQWI2n8RY3tr89YPtBr6NQvQpbb+xyXNm355po9NdiTIQG5d9tG3meMe8c5vLEFk4nf2wuGDKVj1MR167fknkpCyt8ErUVsKHtDp1JnyBoncm8VSgCo5 puWKcLor FvcNTnRaHYWs7xdgnFHm54K0fSBZIoP8oPQlb70c9t61b+MNxYy1xoX6lgyBt/poiCWO4eWqF+1vYAMqCY6XvJvJIDTK3yp18wPGK4/mNrCi0DNBW8ThenNwPqOre4BUZ/avSiF85wAFP1JQ= 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: [..] > > @@ -1336,6 +1347,7 @@ static void swap_entry_free(struct swap_info_struct *p, swp_entry_t entry) > > count = p->swap_map[offset]; > > VM_BUG_ON(count != SWAP_HAS_CACHE); > > p->swap_map[offset] = 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(). > > 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. > > I wonder if we need to do the same here?