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 CD8B9C83F1B for ; Wed, 16 Jul 2025 07:14:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 21AB06B008C; Wed, 16 Jul 2025 03:14:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F1F06B0092; Wed, 16 Jul 2025 03:14:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 107616B0093; Wed, 16 Jul 2025 03:14:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 003F56B008C for ; Wed, 16 Jul 2025 03:14:58 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9941F8028F for ; Wed, 16 Jul 2025 07:14:58 +0000 (UTC) X-FDA: 83669265876.03.D9D27FB Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf22.hostedemail.com (Postfix) with ESMTP id A97A3C0002 for ; Wed, 16 Jul 2025 07:14:56 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mljgQLWj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752650096; a=rsa-sha256; cv=none; b=uj1UAtNOcQisc5zbgbCrbJsFkHvvNXwz8sbYqbfZhFBi/zYvMl3BLTzH4jxawBnwt/jvpX U3t8V3tP8GlF9LwTQox1vl9Babobk2cxQFIGb/P3oSk9nMVRtgR43TxMgXcJ/xO/J8HdOQ SxzAm6mzdn26IZvxVfzSgrQtl8/KdZU= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mljgQLWj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752650096; 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=8/TskkqgAknmlMUUx/sc2CfLPBj8HFNCTNNUaHiNnrE=; b=fxuiDqn79ITbckgfpHvbYDf6UnjaW3ge/AdvnBxKBTS9UU1ddz2xV48DCj9zvmMpPmPPLJ if9cJBGOQAWLrRmf9S3BgL0e7ILx3N3udlNH0CXXlbcfMgaGUG8Wbpnpz0HoeNwfEcXAck 8GseKww/p4V0RA9qg9hQ5IpaJwvBQO4= Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-32f2947ab0bso44685051fa.3 for ; Wed, 16 Jul 2025 00:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752650095; x=1753254895; 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=8/TskkqgAknmlMUUx/sc2CfLPBj8HFNCTNNUaHiNnrE=; b=mljgQLWjx8RCw8JW0MZYg55OQfZhfXnyhQ9oHoFrbj7OL+UlpN7z6dfPQn6v3Smj4G NePxIgL5a8bFA1SWvayd8dfcDbr966lxbtiqJ/Xur5jP0aY87IhHRTfa27PdDjm9acOH DoRNKI5fJT0NR79HJ2U3VtJTLALQ7GuG4oYZxQKUBtY1qiB9uEVbmSEiBLUTDl9308X6 O3gjzU3qGGeE+DZHcTFvMj4o10TnVowD4reET0nfFAcUBifEbM8z9yiF0JldviXKGwQk weERag4olJ7JVO7sYsFCkqA5vwJUXz6P5X04e1ybnVLt80GbzsKO+ziKivJS9pjMx1K7 oPNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752650095; x=1753254895; 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=8/TskkqgAknmlMUUx/sc2CfLPBj8HFNCTNNUaHiNnrE=; b=bii/BKWDytZHiNfSkSc4bvNVoG8y+o9x1Jg14UWpKFydp0lUThwGe+jTrwcIxHLhCC MuOXM8vt3ZWbbYBdw6YfEZY9Yo220Jgj3TotpJ7lhiMQQiGr28slnMX2wztyxdXLiMyI vCEiawCeqlZL18AA80231K0tmg1ljO2nu8CUt5pvw1qGIRmpfCSEKYomPOV3Ps0BLxQ6 1TXb/nwURR6Ir7JkZLybb/LkLEbZVM0IWno1KPm19IsOhhkePusWnctJYla2hlfG5N35 pO2rTVGzSXuFirY1xIQ5UN7y9P/SbZDWlCnyBjUrJkGuEyFs+pUrQeDpnSUpE6QW4WTJ vghg== X-Forwarded-Encrypted: i=1; AJvYcCWGp461x9xUkGySMzXiX0gSXZb/ifb4SOfGKcp9uvtPhFjPBqo3xU0+zOCp9rL9dPA3lf10bI/Tow==@kvack.org X-Gm-Message-State: AOJu0YxivRNx8Pwld53qbNEqa2V5DIlY/jJe0gvTD6QsTkbWwjIuqL4Z lM4J1HX0Va1v3flSIkWyDW4+BJW59DKQmjEARK02qI9uoZqp4QAWzrz32KJR4s/OOQwdvisvd3z WAiQQb36Fp2tAXP/O2pIh2+mNYGRWchQ= X-Gm-Gg: ASbGnctwbn2rbIqiBc+DUWFm1QtQ9b7gGEI4L7xlhfV/xfxEhFzcv8kOpMe41PCHQwP h7ieClccLjdRMtckcw0+5plKUhF7BC2oaShJKVk/paW6Xp1jLZrF3E4l9t7aOuYV1BiomyXQ3nL r8e9tizCy1uwN578t5F9lGgiRqieXpgvzNSQaNKB17eF0+y/6qfMbXMNI2CoM8AE9J0wLGR2SC8 7NrnA8= X-Google-Smtp-Source: AGHT+IE10OfJxxq0wMgT/q6inJbMeGnFb6O/fdLgd9emra6LAIDXacfuGpylhnN7yvgi7/OpTqFIOaP6C6WqelkphNM= X-Received: by 2002:a2e:b8cf:0:b0:32c:a006:2a36 with SMTP id 38308e7fff4ca-3308f5c6b99mr4581721fa.20.1752650094463; Wed, 16 Jul 2025 00:14:54 -0700 (PDT) MIME-Version: 1.0 References: <20250710033706.71042-1-ryncsn@gmail.com> <20250710033706.71042-7-ryncsn@gmail.com> <57e82add-b8d5-49cb-8a3e-58c7c65768d0@linux.alibaba.com> <7454d5b3-e8a4-29c2-ea00-435821ebfd37@google.com> In-Reply-To: <7454d5b3-e8a4-29c2-ea00-435821ebfd37@google.com> From: Kairui Song Date: Wed, 16 Jul 2025 15:14:17 +0800 X-Gm-Features: Ac12FXwhNHAkGIzUr7aHpF-30otPMcr6GxMfvF6LW6zD8vDq5BNGf6-ioRiGg0Q Message-ID: Subject: Re: [PATCH v5 6/8] mm/shmem, swap: simplify swapin path and result handling To: Hugh Dickins Cc: Andrew Morton , Baolin Wang , linux-mm@kvack.org, Matthew Wilcox , Kemeng Shi , Chris Li , Nhat Pham , Baoquan He , Barry Song , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: e5ijce5iio6bcmu4a1rg35erecxzzczs X-Rspam-User: X-Rspamd-Queue-Id: A97A3C0002 X-Rspamd-Server: rspam02 X-HE-Tag: 1752650096-968495 X-HE-Meta: U2FsdGVkX18ylHWsCj2N/Vuws2kRnp4F0OjVNmH2V249GfE/VEpnG2H7VbsQVeJdU8nkAnKtbEy5SlSF8aDwAbzuYJlwP9Dxvx6OOAj5+mMiox/PnzK+QaG74YVrZrLlpabRZf1qVK8Fge7y/qsrjOIgEeWnHt1wmu0mAcX7ZPsVoQjRfj0pf4y78AvTclQEVQhAk/qaAuV0i/cT8f8DJQR0mbdNgSbjA7+ThXPzlxOibJi8KXjjEz8EZJIglubHZkQDi7z3IjPrPc+yIjm71qXFretaXmbAmI5ooj7s5x+tHFLKlwE8wzuzz52ZRnmiZ3FSgVfsu0H+BLG4Uq0AtHS91SOvZTxmDeEJU8MTvnk1Z3yrtfA++kyhONIGpz5jM4ycHhFQAsNBoSrPmbut1ko+oC3NTHpie/JDV5xwKu3LdmVDzAkkBx6lOq39nfiI3Q5WJVwCbZfBOQmcd5fn21QnPszHDn8rgMawUaRctcMKHGqGBMblmWROQKMIV344wRtrIr/D8S894LDEbTrB1M111huybOp1Xk367FLgaZyGkwJjuvWhDkn7Z1j54B6hnKytMJ/r6GGPVjbJoZnD1M9VvePoghiLUEwTlwezKZMGaLE0rqfZb6gi8l6EkyUYnqzGmBZKqKhLZrHFAr4zBh0jUCoIcbgedlS2GvEwRb7wJJcgupkgHvKXS6Ni5CDn3lwe/F+aE1mUQhW8a0Mtwv8O3PPQFVc6jWDnBQ1Rcp79YLFx+lP32ou1A6UP8C0G8hV5QLjNowSUfbQySBh60mmy5s33sptwSP4ZJSih9eOQmYgUhL6+6ObkPrJtIAVhdxtSUjy3iDwQeaci0/oyoYHKVPDi3lxUWBfEMFlkIbSVU2sfUfa5FAR80CGHN9UUr0OmEEyb8vN+oW7lfasX6VlkQuMupW0Zi3ektxvXMXbseN8s5QMQ3RjnEHiAH3KFy1rQsrtCpEDtsRWymKr oWQwQvj4 qMFJ0chmF07FDShBYSq5lCWwoAp/vvp2cOQfRi00PboKi48vygl9r7kr5ShsQJy5RS5le5juNOjmJoLuxZLkZFQiKgFf056AX6SD4ZogNsUMImD3L4sSEqA9lsTfKjBVYVZMXVgkHHh0sNFlAeddKZ/2F/M1e2hgalXx0Yrf9TkE1jL4OrEw3rRammhKyGr6M2v6fjPRKWwArd9qiXwH/vMF9w7+awHc9mdzU+CQkqnRxiFwmRA3Cvrq91oOrwM38bH5Lkn42Hwa4F1byzZmtcS/JlLgiYW3vDbkIXawTZXlOpzRrqqYOzftSUfiY2bQBdJwF5UppgWeNgKvNNv2Tq/5jBATzIrMKfavI0fk5/Qi85r45MO9jttPYGAhy6f+DgLVI1IR4cA4f8/P6adJOTEimM7LVkxp51FF4kl/36HRYOBA= 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 Wed, Jul 16, 2025 at 6:10=E2=80=AFAM Hugh Dickins wro= te: > > On Fri, 11 Jul 2025, Kairui Song wrote: > > On Fri, Jul 11, 2025 at 2:23=E2=80=AFPM Baolin Wang > > wrote: > > > > > > > > > > > > On 2025/7/10 11:37, Kairui Song wrote: > > > > From: Kairui Song > > > > > > > > Slightly tidy up the different handling of swap in and error handli= ng > > > > for SWP_SYNCHRONOUS_IO and non-SWP_SYNCHRONOUS_IO devices. Now swap= in > > > > will always use either shmem_swap_alloc_folio or shmem_swapin_clust= er, > > > > then check the result. > > > > > > > > Simplify the control flow and avoid a redundant goto label. > > > > > > > > Signed-off-by: Kairui Song > > > > > > LGTM, with a nit as follows. > > > Reviewed-by: Baolin Wang > > > > > > > --- > > > > mm/shmem.c | 45 +++++++++++++++++++-------------------------- > > > > 1 file changed, 19 insertions(+), 26 deletions(-) > > > > > > > > diff --git a/mm/shmem.c b/mm/shmem.c > > > > index 847e6f128485..80f5b8c73eb8 100644 > > > > --- a/mm/shmem.c > > > > +++ b/mm/shmem.c > > > > @@ -2320,40 +2320,33 @@ static int shmem_swapin_folio(struct inode = *inode, pgoff_t index, > > > > count_memcg_event_mm(fault_mm, PGMAJFAULT); > > > > } > > > > > > > > - /* Skip swapcache for synchronous device. */ > > > > if (data_race(si->flags & SWP_SYNCHRONOUS_IO)) { > > > > + /* Direct mTHP swapin skipping swap cache & r= eadhaed */ > > > > folio =3D shmem_swap_alloc_folio(inode, vma, = index, swap, order, gfp); > > > > > > Nit: the 'mTHP' word can be confusing, since we will skip swapcache f= or > > > order 0 too. Please drop it. > > > > > > > Yes, thanks for the review. > > And a few words after that 'mTHP ', I keep wincing at 'readhaed': > Andrew, you already did a fix to remove the 'mTHP ', I hope we can > also persuade you to change 'readhaed' to 'readahead' there - thanks! > > Kairui, I'm a little uneasy about the way this series does arithmetic > on swap.val, in the knowledge that swp_offset(entry) involves no shift. > > Perhaps I haven't noticed, but I think this is the first place to > make that assumption; and a few years ago it was not true at all - > swp_type() was down the bottom. Usually we would do it all with > swp_entry(swp_type(x), arithmetic_on(swp_offset(x))). > > But I guess, let's just agree that it's easier to read and get right > the way you have it, and make no change: if I try to "correct" you, > or demand that you change it, we shall probably just bring in bugs. Thanks! I think maybe we can introduce some helpers for things like rounding the swap entry later, we already have other similar helpers for swap entries. There was already same arithmetics in memoy.c some time ago, and I remember seeing people doing this several times. Current swap values are OK with this, will be easier to track with a helper. > I'm particularly glad that you now avoid SWP_SYNCHRONOUS_IO readahead: > that stupidity had very much annoyed me, once I realized it. > > Thanks, > Hugh