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 1CEC8CF9C6B for ; Wed, 25 Sep 2024 14:21:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 746446B00A8; Wed, 25 Sep 2024 10:21:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CE4D6B00AD; Wed, 25 Sep 2024 10:21:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 548396B00AE; Wed, 25 Sep 2024 10:21:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 313BE6B00A8 for ; Wed, 25 Sep 2024 10:21:55 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id AF015AC790 for ; Wed, 25 Sep 2024 14:21:54 +0000 (UTC) X-FDA: 82603474548.15.9139613 Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) by imf19.hostedemail.com (Postfix) with ESMTP id C8BD71A0011 for ; Wed, 25 Sep 2024 14:21:52 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VQeV2Dih; spf=pass (imf19.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.210.43 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=1727273992; 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=QUX2R/4DKEm5BrQh684qt+Rp2UEcR8k7YIpN8oCAb7c=; b=OLpjDYaq7eMM712I9c3kNdWTtYTzNMjfjOcMqd9zNNd8qJI5oRW7+deWzcLjMKO4A24rx+ DzVaZyXrs0ObVod2dz5+vHa82Og9SylnHiNiinxnQyzrEaYq5Wpv9nPSvS4kuVv6avYHlO lRgQdAGIauVPs8jRIsx/N86vttOSBFk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727273992; a=rsa-sha256; cv=none; b=A0FjxwY+IHyF2B2XPb+YtEkdOZ/cNZQz/2pqqD00Dw/3WmREPLOW1Gx6cFby1iNt7nQEKC +4a6OBM5qNCe5jixQ8/thy6YmR4DZ4kfs0EcYdFwdVZlywt/Tt7KBgvBIJHgM6pKfx0Thy CsQBoJCO7wcO+vWf2TP3TZKOJTP8Iz8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VQeV2Dih; spf=pass (imf19.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.210.43 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ot1-f43.google.com with SMTP id 46e09a7af769-7091558067eso2800204a34.3 for ; Wed, 25 Sep 2024 07:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727274112; x=1727878912; 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=QUX2R/4DKEm5BrQh684qt+Rp2UEcR8k7YIpN8oCAb7c=; b=VQeV2DihfNcsNW0CauJt+ZCBCKK8ICDSuYNBYVzyoQvyPzIBaXmw5aTL+LEKE7/He8 7UDt8LzmnosJbJ/gQeLsv1FscMwAhA19oayo/sSfV2DaVeuQ0l5jsPSF+h/UtvMx0vP/ GLFR/TZAV085EHa1JvdRO9U6JhuC4F6xsJE48BsR5MMOY24qHdI5ETQ+LZGO5bsHiPKM iSQHPwLEhhGfBn9oOQzOfkohbMSTjUzwksdKzZdJxDYfu8xXsx02F//k6ZasPRy7bzHd Ww+KO4IFcHPSAZw8wlMYOt3g+9L35Rp5Fo6CDn47v1jWWS3U1wPYLI9Hs1pjWYkTaZfZ Ku/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727274112; x=1727878912; 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=QUX2R/4DKEm5BrQh684qt+Rp2UEcR8k7YIpN8oCAb7c=; b=INxACejEjbeeV5RMxBZcxiS/QxsHSQDqk+Ro57Z2tXqsE95iApTIhwqOcMbTiJF5pG U3x7sWyfTnVMoeiivi+0FapmG/7o0r795locm/yoxEoGY75xcKZf2hOwPnhWWrqnixa5 nRWX/uq9NLd8MxdyXGBkIicfyeN4lAAF56iXr3mHb4jpClIR7gv6UE4OuGrJzxyAMg0X bHZjwsF4359It+RsAm3lvI00Av7maDGnV/J008r4uzkuEvvcBIe1s7abDkcLkuC1vj/M I1pT6pQrQbdFX52i0VEQRdHofTIUv4sr64/aZ4PNshC2aY4190enSMGj84c5UQN0dXJQ MhvQ== X-Forwarded-Encrypted: i=1; AJvYcCXw/xtdLpq7kUTyADt/kmTDXlEwpHiT9JrdTGT/V/Nw9EIl67eOfSZDruDokm8CEGalGGI6rHlRZA==@kvack.org X-Gm-Message-State: AOJu0YxbrvoyjK0wq5IdIpW8MgA0K6/wP1EUsKppsUUAX0kU20O8ufqG bUUW/kvlGstyLbJDt57jvODmvw2W/p3IGrUpLjcXHIB9DEuTxsxmumlF9XGQhcjP3WYTbazdB3C cYwKYstiCzWClhVaZhWryERU2L78= X-Google-Smtp-Source: AGHT+IFCmjMMMSz3UuZaFArM30/mfTctnxogkKFwe79uHL6ltwW9DV/zsCz+yYFCuz/ixoc+NVYDIsOKsp+veHgdo5M= X-Received: by 2002:a05:6359:4588:b0:1b8:4598:31e2 with SMTP id e5c5f4694b2df-1bea86739f8mr183914155d.23.1727274111662; Wed, 25 Sep 2024 07:21:51 -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> <87o74cryhu.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: From: Nhat Pham Date: Wed, 25 Sep 2024 07:21:40 -0700 Message-ID: Subject: Re: [RFC PATCH 0/2] remove SWAP_MAP_SHMEM To: Barry Song Cc: "Huang, Ying" , Yosry Ahmed , Baolin Wang , akpm@linux-foundation.org, hannes@cmpxchg.org, hughd@google.com, shakeel.butt@linux.dev, ryan.roberts@arm.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-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C8BD71A0011 X-Stat-Signature: bekozca4hr55i3u91p1b9zp1zd4bjwpg X-HE-Tag: 1727274112-466696 X-HE-Meta: U2FsdGVkX1+cnRRIiwdF4ntA1UT7WpcKVKx9d8TjGI1J+F6IM51Uw7H3/vHgR6TtIi6uTFD48Ag/9yUEBuPzQ9iwW7tHQL1v0E+QMOG+jlXZXbTmJwB9l5f/KRsyKZz0HUuXHOGUSxti22p0706JWT+sAOGrEQjRfDkOz3yIThj8ZENJKlB4nHfRfkJaAHdLKfhj8y8uG7DqQ0cV1FwGMsHK1eNNcgX4hc5KSj0f6dxsbcPL7H17UV5HOrMsL/lBHxYgZSsz0yHl/UnPeE3Etcmw164wXCVR83RKMOCsjlYQ5SdHgDZeVi8UuVPoCMeHI4cKS6ogT1mnhbzl+u8LwxNGlnG3xWmiu9bjF4CEENRFDbbR4n4lc5lInLz7H5Fqkr9wKqWAOueLvUkxohugPLlGMmn58Jf5FtnQmjJGitF8UINfc8JkInGoSTaJRJeMc/RUaFrbfo324l2XJwWzzq0mj33atB/5o2vinSTmuha+J51f8rJKj7UKwDTNjQyk9wResvJ2R8rxjuc2w9n05NcZYA/o7vbRVbwQy1XN+oSYU05v3pzB0pOc4G/gPFgrHgmvXMK3dqieuFaLOHdjIoKwZjtKZtYlbt6u3M0arij880+RcgwptRLa1v0bRQe5obU7D3jKaoKTh4lK79eOthxr2dQxXvt/Llh/3bdiRYX9b+P7A0DFpp4Z4GZVqvE+rDOAOvAWUtoXwbRISeo4X4pqXBGW8YZTrA3rUSyg2zKkK0lgBxqyJkdVKXee+b8C9Zc82uv2RRlFvmlB5uaR2w1Myya3gEZHId5780cb3BZsnAXmJeA7MuG9OrMXr/+mmPNETjoucgpnxqnheazzvEq90uL+uav+nA2w0DUZ/RC4L/1+2uoa7Xefshb+ffzv9lnYXmbxDeNkVVw5vI/QMtiql01k5mAtPlJou+FmwRO2BO/SUipoZwoG3T535liDFbLBUpcGVahyelrF6mf wyDCt1R8 3j1hL80czkTiAmes8fZZGvAJjFXfKBSzES4nrOInnga1Vxv5vVBrdvdoXv9kcbMEq5wHyCw8TtDm30aNXtr1nbNIQDsx9lXYLiT4VYLD8ROstbukXld3ZFeHIvCMYD8Xuha0zRov7m1gk/HWZi0ug6K44tyxL+xa9xU1tB55BM5ZTDcMLn7+CEf/1nupGg35+JDZzcDSwzEN1ITrZUDvZmKiaVIH6m+YEKsZt6LFdLnUQCGj/oZnCtXZTM9lyneLEQrq45r6kn7HGY0JEeWKkw56vpa07DZoG8gL443H3rI84ZO9KQZ6deaLDe1eMhgK9V2PKWWcJQmIZggU3ET/UKmBce344WTJGYU4ax1/dGveIQiUfCUY7Qu8dN6wK1TN/sKDlkn901kooiHOx8+0hNR8ngsIdy/UO0kq+Z0FIDajM6hYfXzxAZoXdxA== 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, Sep 25, 2024 at 12:33=E2=80=AFAM Barry Song wro= te: > > On Wed, Sep 25, 2024 at 3:23=E2=80=AFPM Huang, Ying wrote: > > > > Nhat Pham writes: > > > > [snip] > > > > > > > > My understanding now is that there are two for loops. One for loop > > > that checks the entry's states, and one for loop that does the actual > > > incrementing work (or state modification). > > > > > > We can check in the first for loop, if it is safe to proceed: > > > > > > if (!count && !has_cache) { > > > err =3D -ENOENT; > > > } else if (usage =3D=3D SWAP_HAS_CACHE) { > > > if (has_cache) > > > err =3D -EEXIST; > > > } else if ((count & ~COUNT_CONTINUED) > SWAP_MAP_MAX) { > > > err =3D -EINVAL; > > > } else if (usage =3D=3D 1 && nr > 1 && (count & ~COUNT_CONTINUED) >= =3D > > > SWAP_MAP_MAX)) { > > > /* the batched variants currently do not support rollback */ > > > err =3D -ENOMEM; > > > } > > > > > > At this point, IIUC, we have not done any incrementing, so no rollbac= k > > > needed? :) > > > > I think that it's better to add a VM_WARN_ONCE() here. If someone > > enabled 'nr > 1' for __swap_duplicate(), the issue will be more > > explicit. > > ying, i guess you missed this is the exact case Nhat is enabling > 'nr > 1' for __swap_duplicate(). and this warning is functioning. > and he is trying to support the nr>1 case. > > https://lore.kernel.org/linux-mm/20240923231142.4155415-2-nphamcs@gmail.c= om/ I'm only supporting the case nr > 1, when there is no need to add swap continuations :) That's the only current use case right now (shmem) :) 1. Keep the non-batched variant: int swap_duplicate(swp_entry_t entry) { int err =3D 0; while (!err && __swap_duplicate(entry, 1, 1) =3D=3D -ENOMEM) err =3D add_swap_count_continuation(entry, GFP_ATOMIC); return err; } 2. Implement the batched variant: int swap_duplicate_nr(swp_entry_t entry, int nr) { swp_entry_t cur_entry; int i, err; if (nr =3D=3D 1) return swap_duplicate(entry); 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); } } } } return err; } How does this look? My concern is that there is not really a use for the fallback logic. Basically dead code. I can keep it in if you guys have a use for it soon, but otherwise I lean towards just adding a WARN etc. there, or return -ENOMEM, and WARN at shmem's callsite (because it cannot get -ENOMEM).