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 6A749C27C75 for ; Tue, 11 Jun 2024 19:33:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F376C6B00BF; Tue, 11 Jun 2024 15:33:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EBF868D0002; Tue, 11 Jun 2024 15:33:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D39C16B00C4; Tue, 11 Jun 2024 15:33:43 -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 B64D26B00BF for ; Tue, 11 Jun 2024 15:33:43 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6796A161610 for ; Tue, 11 Jun 2024 19:33:43 +0000 (UTC) X-FDA: 82219607526.26.B18ABAE Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by imf04.hostedemail.com (Postfix) with ESMTP id AB97E40011 for ; Tue, 11 Jun 2024 19:33:41 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kBc79hpx; spf=pass (imf04.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.170 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718134421; 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=QGtzdB8knDd9uVpWyNbE1brN7EN38ArWVMjYz6tbA8E=; b=o28h8gPA+8PrebYuT73rOemCBEiSMw6uoXjaCX/mrd2PYCfjCwBGEi5UkvlVuiiCDS8ddY UFUhnMp2PiqJLxfvhmV+rq/RjI6rNzL8bkOvgwfzvSpZAu9EhXaR7ln3jzfekrNxXDZ7Ty yC1LDpWlogGgCCsAWjbC5CcJBv8iTmE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718134421; a=rsa-sha256; cv=none; b=Gv2j+5ome8cDiBlPJtg9sjDNcC2ilhL8tgiTHCQ8ivy0wDj5KWHBYu94VIqYvEjZLcNBU6 RZ/27yItv2qgM7qWNwDkpPCMu+rZ0mBJoO6jqL/eWvONq43Bhxa3jZcVXjZD4Fp8fflNIt PLR/ES56M9wJpVvAi/N+573eqNXn2yk= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kBc79hpx; spf=pass (imf04.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.170 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-795fb13b256so17606185a.0 for ; Tue, 11 Jun 2024 12:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718134421; x=1718739221; 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=QGtzdB8knDd9uVpWyNbE1brN7EN38ArWVMjYz6tbA8E=; b=kBc79hpxqbmQLyV8K4p+HEEnS6Q8IboZxHnXsNpSvaZmHzKpn0qRvfWAG8twNTtYE5 WjyIoFBXx1ybsbA08xs2nFmrZ1zsUBneK4EDk2GEq1QND8rv72IE9wNA9YuAxtxqihY7 Z6ZkPsKQAuHRkNBRrqKwUD+88KvztIkXUk+Dae5wIzb8qLQMPSHWPNXL+msgOErJgCs7 XU/lr7+iOZVtw3hPrc6BO6yycJrxMZdzzLJ3Hknjz8HYQ6qdQtj+88jgeL6IcUpvNvnv wnLHVgaRc4PzdHALpeyNLE3eVh8AlD+wwKt9dbTuN08KvfUX4xluOjP0GXkjuXU+boA2 Vs7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718134421; x=1718739221; 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=QGtzdB8knDd9uVpWyNbE1brN7EN38ArWVMjYz6tbA8E=; b=C/ZZ2ynUc0GFqPifzOYZyxjTuYe0A6pWdx5tRO9+vp+2fkKSlEpkkdu7BlA391jEyX 7l00KmRlOOiZZ/vHLmmAYAevti39sQQAfzaTJykHaXHGHlat4dvlHmgMR/mfxmWHrscp fC/7z3vsn+yhoZ10OiPaPJoYNP06U3M6lXiqj0w+zDyPEYr8feCjYmwb77E+x+Vc2c6K EwQNAYTx4xgywVN1SfcnOFbSGEqKr9z0gMNbLWhzOn2OQZZ5GJlRJq+5A4CVezmlltGh pByQE7Z6A2vPUQnz1zvChpqDLADwn398E18RZGVjILClMKYYDUuKwmTqVmAauXKmLuW3 zHoQ== X-Forwarded-Encrypted: i=1; AJvYcCVZBt6dhSJ7C5uC+liAachbfdHCB9ZKh00XojgLTvLnt1ZF8KxAuv6CeYjZ06zexAaunUTCxmJPWgjf/I54xIOeWvc= X-Gm-Message-State: AOJu0YzOzbU/6hZPe7Xacpj/uYj6uv9UGtcZbdtCz9aayrU2OdJIuQHF 2uBrJeQwtuRRoe5lFNyyeGGx20TAvybu2djh3e+b0ZUsoEqdtcXIMK+qlvSdqFf2gc3c5rbxTZ0 4uAZjz6oHqQWkD7FzBo7fDF0IPQg= X-Google-Smtp-Source: AGHT+IHhC+MO1Zr9z6Wg7jVXqtwNEJPILeYSXjDsNPiz7wS1EB8kCfVlhBWp0VQpcu59rSs79Z4d1dcaNbff0ZGzNFM= X-Received: by 2002:a05:6214:418c:b0:6b0:820a:db18 with SMTP id 6a1803df08f44-6b089f4870fmr63732926d6.16.1718134420632; Tue, 11 Jun 2024 12:33:40 -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 12:33:29 -0700 Message-ID: Subject: Re: [PATCH v3 1/2] mm: store zero pages to be swapped out in a bitmap To: Usama Arif Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, david@redhat.com, ying.huang@intel.com, hughd@google.com, willy@infradead.org, yosryahmed@google.com, chengming.zhou@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, Shakeel Butt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Stat-Signature: 55k5e3dfm59aqfzengbmxa3saoq3o87k X-Rspamd-Queue-Id: AB97E40011 X-Rspam-User: X-HE-Tag: 1718134421-939819 X-HE-Meta: U2FsdGVkX1/x7yO7raA3HqP4L0adPIb93m6sNMEPKQ2HV/c423u3VmtU2zzxeRTJuv+IhzYsHDvM773lCENX9uDtwhXgxRuyvze4RX91y6yqUH71Trbp39AmSoFFGiMrGXnoZbaBW45uJeR9lkIaH79E3FXXZdOvV+4HWENCHegtVKyUazj3Pk/tlYVXa2LEa55TuRirK30SuY8mX7PrAce+xqf24Guk+j2patThBX7uMTtoUXixD8c8BYU3kZvzTHXueCEWWTnYvws3wYY25thF/6qo0sfkoMp5m9ydwSU9hFb8r5lcii1aV8Vu4PgVxOU/rTTxW/R4ssScDDyzDgxzw6mrkZ+HUoQ3l3MGzj3NL7KvLHgs4FJwFRgJ0wrblsrjU6sGQmz2yW9sVu5j2UWjF3Zn90SccinveoNITyJoKRRhBWOCLBrsHZhqQu1PCwjaAHdTjuIw6HR2O1gY6nGz76kAWsAdx0oOnV/07IZHF9kdgz519WchfwpRHqx7XrzXMe4jyILUp7BzUR1ZrfFjGpvLga+qzXbGXJkbTyQTjCYr8rv5ktZmyCnWOK4WORNF9d54TogMNwp13iu6DTG4ZCkqj5Vr3Ab3E8vlo5efYY5y1T3pAS6cRq2SY07FZWTiRCRP9WQ21P9L40G7iFTm6c19l9fwWgIOCE1Pp1ow+PTPzgTBDzgN607n4NyxqIYSHyT4P9Y/ByHx0kuESisNBxY27abp1f/udVJtROlJG+PhZfJqFHV1V13sKGykjkghb43Kd0yo4M8zbTYQzd8sjAVBBoVjsuueBMoeoJMnarIvCpHeUFGuS6MnTbeGabUdCfoBQwNa4NIgfimyYes3X43Oj8ziBkhSnHfOvElkCNP4IDCTbXukUEpAWA5lTm+xNeAu0R77pyqclhXr7N3/eW8YlNouAVGleolBBheKJk+7UuQ/OxSdWFK8WsmsIAj2Rt/67vv5lUy7L4x NYAz5CUy uTRG15coP3mEMD7uJNGKOR00mwGtDFIjcpvmNGaSTJLSAHgJBrRRcfjSH+hHafZVxaVNlC2J0cwBKvobjB7vn6eNFWQ8PjuF9ICsBR5Nx5Vb+V40bvCNU97Tvx4yA6VEioSb/sloawyYZMq3LVYLbNXh15xmEB9PjUS7/FNZvt0VoAPSSmZHOV1U/BASbcat4WgMXuTMapaLEsrWlJB//0ItdzhgslYqechSya/4NrjH41OzoChUNniSAYPhUKbPiQ03bPKr4y1Lk7hq7sVEL/+8uMooovAFjPVT9 X-Bogosity: Ham, tests=bogofilter, spamicity=0.006585, 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:50=E2=80=AFAM Usama Arif wrote: > In swap_writepage, with this patch you have: > > if (is_folio_zero_filled(folio)) { > swap_zeromap_folio_set(folio); > folio_unlock(folio); > return 0; > } > swap_zeromap_folio_clear(folio); > I was concerned with the swap slot being freed and reused, without ever being read :) But looks like it has to be properly reset before being reused, so all is well on that front. What about the put_swap_folio() -> swap_free_cluster() case - do we need to handle zeromap bit clearing here too? Looks like it's clearing the swap_map (i.e returning it directly to the swapfile, allowing those slots to be reused) here, and I notice that you clear the zeromap bitmap wherever the swap_map is cleared as well :) I jumped around the code a bit - in free_cluster() (called by swap_free_cluster()), there's this chunk: if ((si->flags & (SWP_WRITEOK | SWP_PAGE_DISCARD)) =3D=3D (SWP_WRITEOK | SWP_PAGE_DISCARD)) { swap_cluster_schedule_discard(si, idx); return; } swap_cluster_schedule_discard() does clear_bit() on the zeromap on the entire cluster. We also clear_bit() in the work function swap_do_scheduled_discard() (is this redundant?). But what if this check is false, i.e the swap device does not have the SWP_PAGE_DISCARD flag set? Are we not clearing the bits in the zeromap here?