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 0DF6AE7716C for ; Thu, 5 Dec 2024 15:20:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E0926B010D; Thu, 5 Dec 2024 10:19:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4DF696B00C8; Thu, 5 Dec 2024 10:19:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A87A06B00BC; Thu, 5 Dec 2024 10:19:09 -0500 (EST) 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 AC58A6B00AE for ; Wed, 25 Sep 2024 23:59:27 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 523B9C12A8 for ; Thu, 26 Sep 2024 03:59:27 +0000 (UTC) X-FDA: 82605534774.04.06C545F Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) by imf24.hostedemail.com (Postfix) with ESMTP id 7BC67180006 for ; Thu, 26 Sep 2024 03:59:25 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=quarantine); spf=pass (imf24.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.170 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727323032; 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; bh=6hQUpgRODlbAfF7DhDSFpWBPEN8hlhzAVagWOO1HVI0=; b=zd63izalyNCaC16rvkKyeqESU4YaiR1jux2IhPYakdI0aRKBAdnurnan5QlU5ejiIc5WoC Rpz2cXp7lt2tj8aCia01aEyOZRYuP80HviBFVUtKH62Fu/CytY9p3z1Yx7C8xW5W9zk7Cw Epp8zv/n6KQ9GfAOFYWzfbTijZhyxuQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727323032; a=rsa-sha256; cv=none; b=X01Si+02KIq8/Q8pBqPLxD99q1GTWatycKYaUQM8eLdPuaij3Vsy/r1kwU1TOlrSnzLGFC VBG1yihn0FTcwVt8RCRGJCjJ4ze1li+9+w2MX8DU/528fWnCxO4FGg6v7tlNrKVX4hwTmv /jA6olv/qnUYOL2gNVLejlSIASibpeQ= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=quarantine); spf=pass (imf24.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.170 as permitted sender) smtp.mailfrom=21cnbao@gmail.com Received: by mail-vk1-f170.google.com with SMTP id 71dfb90a1353d-5012813249cso173284e0c.2 for ; Wed, 25 Sep 2024 20:59:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727323164; x=1727927964; 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=6hQUpgRODlbAfF7DhDSFpWBPEN8hlhzAVagWOO1HVI0=; b=wRF/US6usouVg9vxJ8zhfRevQE8l/x50i2MebR/oPHP7QaqYdEZLyj/ZWT61E/kI7g JrGH/V1wIeNk2jenRMvFvy1X9XX8uwLPhVUQV94FICRyC7nyV8gxrgXjrAZ7p6XX/GRG a7O9d0soc9s9BSFM3FcCe+41q1G9mKYmakd0fw2DZS9LInN5iG72a+ruZHY2fcFM168X kmq4bPC+Ux9cqrXB4/i02GNEDDGU11FsV+k6wd0qioR2nGX7fP/5947yfraP2Rawp+4B ScqWymb5QqF8YH5ix54bmYNQmYgt7T30RygGx1JmGx5H9m5tIsWPlDB3ElzWt6g1WLV9 DUhA== X-Forwarded-Encrypted: i=1; AJvYcCX9n8RO8lDhuAWjOFqHfn4rziKKwoCpk+9rmgZAJ4GSvSZRGMqWPj6Eseia3AxYtD2t03zkiZVCcQ==@kvack.org X-Gm-Message-State: AOJu0YxDPDCXvh9xl9dTQuRjZlbnUxHsJXhJ+sgRHqv+4nyhhs6JAyKq 4e2CelF4/vt6q/GSKmCbtXWuFZuEWV0y+m3wYYq9TtopIKGNLc1IN8EaLDlt6LzKfKaHEbp4AFX e7WflwJftlpLWjDmO++Ee1+Rtu1c= X-Google-Smtp-Source: AGHT+IH0dJd2dAGLNIJvgejecFMXp7oCjM4hEifkxYLdjHWSYZMIGum3njZp7cIFqhZLybEPwYhD2eB7uYFNjj6DJlA= X-Received: by 2002:a05:6122:2226:b0:4f6:a697:d380 with SMTP id 71dfb90a1353d-505c207af66mr4894607e0c.10.1727323164429; Wed, 25 Sep 2024 20:59:24 -0700 (PDT) MIME-Version: 1.0 References: <20240923231142.4155415-1-nphamcs@gmail.com> <4d38c65d-760c-43a5-bb47-8e0235c13a51@linux.alibaba.com> <9a110f20-42ad-468b-96c6-683e162452a9@linux.alibaba.com> <85a2fd61-93d3-4cd9-95a3-e9eaef87286b@linux.alibaba.com> In-Reply-To: From: Barry Song Date: Thu, 26 Sep 2024 15:59:09 +1200 Message-ID: Subject: Re: [RFC PATCH 0/2] remove SWAP_MAP_SHMEM To: Nhat Pham Cc: Baolin Wang , Yosry Ahmed , akpm@linux-foundation.org, hannes@cmpxchg.org, hughd@google.com, shakeel.butt@linux.dev, ryan.roberts@arm.com, ying.huang@intel.com, chrisl@kernel.org, david@redhat.com, kasong@tencent.com, willy@infradead.org, viro@zeniv.linux.org.uk, chengming.zhou@linux.dev, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 7BC67180006 X-Stat-Signature: pj3fk5apmqpbj7bqxztpmssime84hsbt X-Rspamd-Pre-Result: action=add header; module=dmarc; Action set by DMARC X-Rspam-User: X-Rspam: Yes X-HE-Tag: 1727323165-893801 X-HE-Meta: U2FsdGVkX1/XXu/r2v8fHGfeM8OVnqd0CHzjAbkMpnDk1+OdTKIMQZJdOhAv2+N1I6XO0iC5480q3X/dlCvTJLaH/NBHMWeZNl2f4Od2pdi0hhAC2zqBfFELgbXtdOu1KG20ZhS206HMMUaRy0s0OxCNZb8JrNInJOtAa5W8NauBTegBipvDUuZLHDBPqSxfOdcVakSOv34hVnxrr2urctTRltIsEOBrF2MRzCDAOJwj6KpW+HvL1/SETZY5+EIcGEvhBbaz4DNTrsT1AJNXdYxRjyvs5viZL99l3guj4BWbx0SIPZnAd5kw1xEBJGvIsIrWBBP3eYxspuQ2I8+kvLJlISrJBXON4Uce2od8xnCI6AcTsxns6c+FRyYr6rVFOewyQgVquiwcvob45tE3Ao9108KIDZvcbDDHRLuii+DP1fDrOrgS68Zn/ael5kd62hEHwSv7mg90xmXU9AsqllIQOpOIvYd8VKOBybkIugKMKyJH6UWpwNViGvtAcFPHJHm1MA/nJtw6oGRk7N2vU5z8Qm63KWlxGCFxemMf2fngk6pt6MAP1ZIH7tYMTZWWNKnegzSTju1X7LkMJbXy879Fd9IfGXuE6PmvGNPuQlTdMUEn3ap/Di8GDClwANAVDeGFy/8qVPd0EHjJrfTfa+E6VaHbBgByAE5NUBP89qwMIlcBJrlBDvon6S38ha+GEIK8qrmcpJb4FPlT7fhJ8Pi4KGhEmu97bX4vEEIzNsyvm7fP7W20FPOwofpE/S9VtSsykBbpjnyoIODj82JyG5XGncY4wR+w1ylYsa8pfCu207D+D5S9MJNrrBIuSrLcYw3xZG3r038LFqepURAQrKlwh6k4RolKUdVOqKwB+S7AwjEcmkBUdJOI6Bo6BrHZv4vu1lN/sO8l0TPKCtUA4VJAGx5C6IMON8sZoyKt00vx9yJWocyW4hygyU+qEHlVgd1Q4AbFnjqc197djxD dEjBcHuu P9c/o2DyanRpxjXmvn1D7wuDYRGKvwiOjd5LmXMzGFeyVG28/2kAsERUjSbKnRDRXc2Rx8gLFQcMOq9ZUzkSBt+vpOmpiW1A//FQMfJYjPBC9qYdPgyPdxVDZnDiqczy2lNm2vUjbGjAcwRxnO30J28cF4mHTNcU2RCgr22CXl57Gx1DWXpV5iBSDw/1VuApt6/A6djokjbjzV6UpiiIkSTwnOWQ+vChWhYkcaG7OX+C7rimdCvq3IsKSc337EG5Q+TBR+tBuhEffOYorlhG+D+XMr4PnOGqqVLhq4ynCmCw10o/NWPaH9Bsd/kihODCsLZQuAV6dgHgo3f4uHuoUhPeWIrRBSWkPMMP7dwVJesEhUrO17MGgwGYI7GqAjMV4toVD X-Bogosity: Ham, tests=bogofilter, spamicity=0.000069, 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 Thu, Sep 26, 2024 at 2:37=E2=80=AFAM Nhat Pham wrote= : > > On Tue, Sep 24, 2024 at 6:53=E2=80=AFPM Baolin Wang > wrote: > > > > > > One benefit I can mention is that removing 'SWAP_MAP_SHMEM' can help to > > batch free shmem swap entries in __swap_entries_free(), similar to the > > commit bea67dcc5eea ("mm: attempt to batch free swap entries for > > zap_pte_range()") did, which can improve the performance of shmem mTHP > > munmap() function based on my testing. > > Yeah, the problem with having an extraneous state is you have to > constantly check for it in code, and/or keep it in mind when you > develop things. I've been constantly having to check for this state > when I develop code around this area, and it gets old fast. > > If we can use it to optimize something, I can understand keeping it. > But it just seems like dead code to me :) > > My preference is to do this as simply as possible - add another case > (usage =3D=3D 1, nr > 1, and we need to add swap continuations) in the > check in __swap_duplicate()'s first loop, and just WARN right there. > > That case CANNOT happen UNLESS we introduce a bug, or have a new use > case. When we actually have a use case, we can always introduce > handling/fallback logic for that case. > > Barry, Yosry, Baolin, Ying, how do you feel about this? I=E2=80=99m not entirely clear on your point. If your proposal is to suppor= t the case where usage =3D=3D 1 and nr > 1 only when we don=E2=80=99t require CONTINUED, and to issue a warning once we determine that CONTINUED is needed, then I=E2=80=99m completely on board with that approach. It seems that your intention is to simply relocate the existing warning to the scenario where CONTINUED is actually required, rather than maintaining a warning for the case where usage =3D=3D 1 and nr > 1 at all times? I wasn't actually suggesting a rollback as you posted: err =3D __swap_duplicate(entry, 1, nr); if (err =3D=3D -ENOMEM) { /* fallback to non-batched version */ for (i =3D 0; i < nr; i++) { cur_entry =3D (swp_entry_t){entry.val + i}; if (swap_duplicate(cur_entry)) { /* rollback */ while (--i >=3D 0) { cur_entry =3D (swp_entry_t){entry.val + i}; swap_free(cur_entry); } I suggested checking for all errors except -ENOMEM in the first loop. If al= l conditions indicate that only CONTINUED is necessary (with no other issues like ENOENT, EEXIST, etc., for any entry), we can proceed with a for loop for swap_duplicate(), eliminating the need for a rollback. However, I agree that we can proceed with that only when there is actually a user involved. (There's no need to address it right now.) Thanks Barry