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 10EFDC5AD4C for ; Thu, 23 Nov 2023 11:13:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 678FB8D0020; Thu, 23 Nov 2023 06:13:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 601D78D0002; Thu, 23 Nov 2023 06:13:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A3938D0020; Thu, 23 Nov 2023 06:13:49 -0500 (EST) 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 37AE78D0002 for ; Thu, 23 Nov 2023 06:13:49 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 06F70C125C for ; Thu, 23 Nov 2023 11:13:49 +0000 (UTC) X-FDA: 81488958978.30.4EE857B Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) by imf28.hostedemail.com (Postfix) with ESMTP id 2867CC0014 for ; Thu, 23 Nov 2023 11:13:46 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TRu4n28u; spf=pass (imf28.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.178 as permitted sender) smtp.mailfrom=ryncsn@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=1700738027; 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=BVOejPj0G54Lit2Uyo96eZ6bkXM9HZIazx2Np37e5CI=; b=RKomniDo4lR19pzAHHbRulxCMY7mvhjyyQ4cRv26bj2Z7DEh+2mS1riUSWReVN+sz0SNVi HLn2+c4kBMG0RE6NJHkKXGRQrZI0sbGxSb+6zdiy6qIezx4E0XiQLdE9HP63mMbNI7M0UT XBL8EMQiYH7ZZJbGz0bp8NYSi+noPGk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700738027; a=rsa-sha256; cv=none; b=sheoqHOBXl2i5XppkJQ9FBeQkiMmozpyGnxum7IyI+quJ2qV0OXzzEwOUPvy/4MN/F6zR8 qUQdRX0epIWue92WLFEHgylNXwlTvjtO25cHU1QjvnbA+2th+NTaeQPwDlI6vDmXPfPIHe /gIz9ZONUWG4MkYzNwYXZwk6v0jmOIw= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TRu4n28u; spf=pass (imf28.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.178 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-2c503dbe50dso8910261fa.1 for ; Thu, 23 Nov 2023 03:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700738025; x=1701342825; 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=BVOejPj0G54Lit2Uyo96eZ6bkXM9HZIazx2Np37e5CI=; b=TRu4n28uv+KA0gHGVJkFBJKAt7AibFCgjl4g0XhYrRZWjKaPy+HjnTrwnpP0+n1Cg2 jvYI3aPOR8cNU+RbzFY3lKzDjr7G1j3ubw1r1gnQMChl1Ystx7FGiGcBjB+dV8n68TwO pHTAx1XwuRdvgB7OYmNlHAqNAUvegIVLrsPTRkG/r3V95co2oOSmeu3HieYnqn59LJLd Xblmr88cYHE6IYB8RS2iu/wDI+9H+a6u3c3Q1MuUUp84/zJrGXA8cqTxd+dBXf4pNXb2 UzF3xXnIs5GUnHB5idcfFnda+yDD/G+jbh0YrkS7DFqkue49ZeMitsv+L1JeltgqAhOZ PBgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700738025; x=1701342825; 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=BVOejPj0G54Lit2Uyo96eZ6bkXM9HZIazx2Np37e5CI=; b=Im2PAcXO4tvpvYXcmT3O0XYCCj2V55GiThJfJCywThTQWesyCtLqZ2VzsGnU9PXi8T c2lGl0OpNi4/6DEaScN2WOw+aWm6dqqJ0WgHcoa4xkmVQ80Vox2PHVmAm/pJOBnD7oWr vEeh4GbHuV/pLsUgLqcIgOYEznFoVlqA+lKjepma9h4ODRVCXeXBT651Pyx0m6ShlrJ2 CovfxVUIErtZ/fO4WuI8p068c8dYM5SwBaq9E69Ys2QVwTsNmMClikiSdnaJKgmHz1v9 OCElSFmdxW50pVUEXwuIFjoX0ljPCGB4UAqy0M2pW8zSeA9LXNgDD+/JhnZieVmdSNOX cIOw== X-Gm-Message-State: AOJu0YxiYOf0JNzDt+n/s0LtAx5WRhKveNLA0gr4SL2ErOcv827zGH1+ ONox+Np/Dd0oUI4WF7YBbOPtiqVY+AVQkTOdAHmIxp9+hh/AuPx0 X-Google-Smtp-Source: AGHT+IEGg5VfnCETwTajEapRt0obuhE0/nk0jzOVjxAmRtmGkRRcnk8xi5p89NpdZrTjIxyKqZ70HP5HK6obg5YSRuQ= X-Received: by 2002:a2e:90cf:0:b0:2c6:ee73:a20e with SMTP id o15-20020a2e90cf000000b002c6ee73a20emr3583861ljg.33.1700738025304; Thu, 23 Nov 2023 03:13:45 -0800 (PST) MIME-Version: 1.0 References: <20231119194740.94101-1-ryncsn@gmail.com> <20231119194740.94101-17-ryncsn@gmail.com> <87sf4yaajv.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: <87sf4yaajv.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Kairui Song Date: Thu, 23 Nov 2023 19:13:27 +0800 Message-ID: Subject: Re: [PATCH 16/24] mm/swap: reduce scope of get_swap_device in swapin path To: "Huang, Ying" Cc: linux-mm@kvack.org, Andrew Morton , David Hildenbrand , Hugh Dickins , Johannes Weiner , Matthew Wilcox , Michal Hocko , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: bspz5ympwbx1mzxknhayxhpqyewctd3m X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 2867CC0014 X-Rspam-User: X-HE-Tag: 1700738026-493467 X-HE-Meta: U2FsdGVkX19FaaTUgt61A9LpGnEvREW/LuQZwfqpkBRbeX78Tb+LN5UbAXOgaMzyUTyXvkfYD53rPp6tvE1TawCrOlqp5jhutOOz9yWqh59FyBBvCBkPhsWLHa4IqApJkhqSrUcx1H01UuFXnvZT6q2GCvxfiJYzzhvSy8nlg45/j7CowGYwgTdHbhzmf8R45Skt4I8YrRKe5VBU6NpvXIVa5z+uk0z8wVnzBPK5RgNxuT1TWoOopTtg1HJNsJWVUBzDzYBm20zbzKCFVp4MgsifH96Xukss76wbUX+iv4vW6ipe5l9iSxXLcrIMip03BxVIU83zIuFFGUP28KI7ty5kiLaBfs1a+2jPNuF1pYUM74r23pv/IbJLZNOGbrHak63tLWudSxMXPS7EnkV0NDDFqC529cnCThSvhU//c/lApFx6tytTVayPDXCEqV9ZD9lRvvjEy3efuISe9eerGVTb7tk0N8tmSykWZScuhG8YVyQ+5MNuuVP3PG4ikXUm/FXb1ALuuqXpeOpx2FRsYAdRI8PURTqrjteswob0zrQdXyeq7O8xHThhCbBOg6hpYrMHgDtjmfvWbmYiZwcU/A1yB1M7Kjq4vDAZ1nGN5tkzcnoZlAXWGu7vxK4jNXhurJ0wN0hxKFL09kWkGS5hHqK6Zzbcn+wmmLeck5+9Qt19Upbx5hk+MnmIiVyDBtcH334cvapfmb2WaM5ZvHVVx14U2oYpf1X2LCgA8mNShL0aR9BkbwFjm7LZ3+gASA8iZ9IIaA6zF4nT193G1yay0bCV3rkngZiw0yJiSP7RmCbOsGN6SlxaxXlxTCJkyk1iFF2fZZRwDqnjoxNeW1nUKHbZ2RiU18ko787iYfzBhRWuAqedsWVMbrrdcUuyVOav2U72DHOS/a/ylYibmkm8jaudP9QIJricBw2boSY6795h0A2rcyBzAw3TXhhvrwxvKpgt05yi9Xm9LAm6793 bzBbqyW2 yrzWlqf9C2z0IC7AD3+iUEnYMpjmOfkpq4xhMINMkCf/C+w6pJ/OpfqN0tqrvsm/4ZcUXuFph2FiiFYfOYye8e7C8yZBVEKk4jf+CtSlNhs4Z0YmkP1NTqIhue6kETE0fI0OdqNcLtYGnGe78NdskLCf0niYwBnmYE3LfqxTGxfKotxrFsE88kbtX6TsmgBdpr9/kZw5sndHuHI4T6dk4vrYN7SjaIg+hsCl/Hor8vuBqKJ7IeySQWsJZZKCgWxkVxTosW2XqspfO8Mw6zXp+BVAZughaP+s5rbFYSP7FCWBOWv0YIZ5IwNUKjCNe6F/4/5Dn07NnZz1UmpHsnekwZ0PhFTz1ELeJeYMUXPpWxurRp+WshiSZ/33ydMD/vpdqizbuMzB2M3jgw+dpzHfVnOX4hwZk8GbxJNloc5gmAJbPvabdoGKc7WoCWPKwVHu/StIJsRqbnb2Rk6ZfMTDRE06401XNsygIvrrzoPgwXquLVyjse86vTODLjNlmyLjHOdHI2yZGrlMMqwvh7xipaIMS1Q== 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: Huang, Ying =E4=BA=8E2023=E5=B9=B411=E6=9C=8822=E6= =97=A5=E5=91=A8=E4=B8=89 08:38=E5=86=99=E9=81=93=EF=BC=9A > > Kairui Song writes: > > > From: Kairui Song > > > > Move get_swap_device into swapin_readahead, simplify the code > > and prepare for follow up commits. > > No. Please don't do this. Please check the get/put_swap_device() usage > rule in the comments of get_swap_device(). > > " > * When we get a swap entry, if there aren't some other ways to > * prevent swapoff, such as the folio in swap cache is locked, page > * table lock is held, etc., the swap entry may become invalid because > * of swapoff. Then, we need to enclose all swap related functions > * with get_swap_device() and put_swap_device(), unless the swap > * functions call get/put_swap_device() by themselves. > " > > This is to simplify the reasoning about swapoff and swap entry. > > Why does it bother you? Hi Ying, This is trying to reduce LOC, avoid a trivial si read, and make error checking logic easier to refactor in later commits. And besides there is one trivial change I forgot to include in this commit, get_swap_device can be put after swap_cache_get_folio in swapin_readahead, since swap_cache_get_folio doesn't need to hold the swap device, so in cache hit case this get/put_swap_device() can be saved. The comment also mentioned: "Then, we need to enclose all swap related functions with get_swap_device() and put_swap_device(), unless the swap functions call get/put_swap_device() by themselves" So I think it should be OK to do this.