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 2C6EBC7115A for ; Thu, 19 Jun 2025 01:30:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB5548D0005; Wed, 18 Jun 2025 21:30:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B656D8D0001; Wed, 18 Jun 2025 21:30:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A54608D0005; Wed, 18 Jun 2025 21:30:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 86EC28D0001 for ; Wed, 18 Jun 2025 21:30:32 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 950A65F6FC for ; Thu, 19 Jun 2025 01:30:30 +0000 (UTC) X-FDA: 83570420220.16.4D544FB Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) by imf28.hostedemail.com (Postfix) with ESMTP id 8E4B8C0004 for ; Thu, 19 Jun 2025 01:30:27 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of shikemeng@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=shikemeng@huaweicloud.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750296628; a=rsa-sha256; cv=none; b=wqqpKsNrGn571AESNBR+R5EpJemi88Xssq3gTTRvsrdd/KyRLvokuvRxT+HS/uj+DKvEYh gM2KZS3fRfbjmoaqGY5p1U9IoD3+zKwAXvx50y8tX2EVvGlNGithhJv1fln/gVWG98eu3G 8Z98Dt6UI5H2RG9tcpfhVEgJBW+0le8= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of shikemeng@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=shikemeng@huaweicloud.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750296628; 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=U7FV17R1uQyeXD8Kx7uDa0PtW0ar6jNtUmuHr+htIUY=; b=cCAFMuyfbonSjaC1zDgg0Li+A8PvDCf2KJKAVZBd1UI/Q8N4L5YpdaMX7saKLJ4h0ndtgO 6bv+4FJjEaqQYP16LNWRxFYXuiFyZuTnUJxrE7gDili8+LbJZOWchwVuu5B22OMWF3rsFV CFDBPYQN95yEOjPlpoAdIId7ERJ5U8c= Received: from mail.maildlp.com (unknown [172.19.163.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4bN32T39CCzKHNH9 for ; Thu, 19 Jun 2025 09:30:25 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id C59141A083F for ; Thu, 19 Jun 2025 09:30:23 +0800 (CST) Received: from [10.174.99.169] (unknown [10.174.99.169]) by APP1 (Coremail) with SMTP id cCh0CgCnDH0uaFNoNFfJPg--.54489S2; Thu, 19 Jun 2025 09:30:23 +0800 (CST) Subject: Re: [PATCH 2/4] mm/shmem, swap: avoid redundant Xarray lookup during swapin To: Kairui Song Cc: linux-mm@kvack.org, Andrew Morton , Hugh Dickins , Baolin Wang , Matthew Wilcox , Chris Li , Nhat Pham , Baoquan He , Barry Song , linux-kernel@vger.kernel.org References: <20250617183503.10527-1-ryncsn@gmail.com> <20250617183503.10527-3-ryncsn@gmail.com> <17bdc50c-1b2c-bb3b-f828-bd9ce93ea086@huaweicloud.com> From: Kemeng Shi Message-ID: Date: Thu, 19 Jun 2025 09:30:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-CM-TRANSID:cCh0CgCnDH0uaFNoNFfJPg--.54489S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWFyrZw1rJryUCFWrKr43GFg_yoW5tw48pF yUKa95tr4vqryIkr1Sq3WqgryYv34rWF4UXrWrC3Z5AwnIgr1SyrWUKr1j934IkrZ7C3yj qF47Ka9I9wn8t3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Ib4IE77IF4wAFF20E14v26r4j6ryUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7Mxk0xIA0c2IE e2xFo4CEbIxvr21lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4I kC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWU WwC2zVAF1VAY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr 0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWU JVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJb IYCTnIWIevJa73UjIFyTuYvjxUOBMKDUUUU X-CM-SenderInfo: 5vklyvpphqwq5kxd4v5lfo033gof0z/ X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 8E4B8C0004 X-Stat-Signature: uk4mgiuutzkjt9qtg8d6oqzdoqbpy6k7 X-Rspam-User: X-HE-Tag: 1750296627-647913 X-HE-Meta: U2FsdGVkX182hzKOc3Ys3Ljz1TPLenQ5kzZVIVrHK0krdMPTYrDq/US9vkUk0xE1VpyvnBpQ8cOkevJfxey7naB2hPqntj/ZLsPupK4F7uev5gVBMngh7XHWjNC7S7nog1r6o+D8NwH6SDPiSozdo1w5KMjELPVi3Mzi0XsIJmH3Cc9MzmT/fet6ShGXxDMnbsldzGnDTCM7M8vz+is1Zw7lzLII/IFMKA53o7M6Au5ppZg3g4F9rd89gYtozZBotwWHsIM/zIkhUtkLEZumBXo5G65VxevpbC1S+GlaHjONCuHMoW2rsDWe/L3AFWKe+7ZzgPcncb1pF0xLEN6mIupGxQ2CehW76GOTJgfeyF4n8FZve9sfTmEyPKF+eWMu4/l4k2hcMb+A7I4tqBMl2AcOgXjndk6ZILxS4EjLEdoL1H/YaN1Gg6wZ7ZYoRFopeFdZciA431NqOxg5kaN7+UTX61BkMkQFwgSF9gPuFuB3kzpAkOzxYnM8tPx6nn7HI9j61BakOpz2LO6IyEORI90pff/kyx0wdb7i9ODDgCruNn+iVsGcXHCcopSSaUKnxKQf/WM1CUH2yUoziImRIuTQxkV0DZ5RTfpguI87O6HXhTG8ZtCxqbetsPqMH0n6KDcBU7sjp5+XrwE2Dc6nkW+VoDT6qdLk3iLrohyPWj6GiMdGgEdb05j3hjj0Kf3PcOttt+9SovCNUW39Nc7AMVnPGKvbXWYCsbHQOhstnIKY2sTt4gNDWR7A7imrrIainWv9fJim0KO9vqVHWiPcyNkGbRiDrBh3P4GK9DchbBjYp5ljTykA8oKwOC+EApSCX0F+WFGNc0Pyidy/O+KcZOvIbXdKztgsq0agRiZJWihP3Rk1mCKcLklHKIM4Df26oJ4ybYxJ+WkI9i5Xdysam4Vdhq3vcLWuHAwYokDLDrsjGtl9brV3rj3NjnzNZh72LkHzShvhpVGdAjU74uH GGHeglzQ Zbnwt6ajogdkOLlOWlwMrbxehNaFI61mzhhbCz2L4Svtxnc637eJ+xhqDkdOM4GXVR6CCZD4TRm0ivgAGaUsQBK5pGLm1oplYF7kcOPv8BcnXZeoTGOUQgSf3LCSaii6a+Qsw2O5eulBqtJOpBrr7zu2zekQqnB2CZEVchJJ8CNMDSSRcuTnW++uoQA9qXtvV/M3P 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 6/18/2025 11:07 AM, Kairui Song wrote: > On Wed, Jun 18, 2025 at 10:49 AM Kemeng Shi wrote: >> on 6/18/2025 2:35 AM, Kairui Song wrote: >>> From: Kairui Song >>> >>> Currently shmem calls xa_get_order to get the swap radix entry order, >>> requiring a full tree walk. This can be easily combined with the swap >>> entry value checking (shmem_confirm_swap) to avoid the duplicated >>> lookup, which should improve the performance. >>> >>> Signed-off-by: Kairui Song >>> --- >>> mm/shmem.c | 33 ++++++++++++++++++++++++--------- >>> 1 file changed, 24 insertions(+), 9 deletions(-) >>> >>> diff --git a/mm/shmem.c b/mm/shmem.c >>> index 4e7ef343a29b..0ad49e57f736 100644 >>> --- a/mm/shmem.c >>> +++ b/mm/shmem.c >>> @@ -505,15 +505,27 @@ static int shmem_replace_entry(struct address_space *mapping, >>> >>> /* >>> * Sometimes, before we decide whether to proceed or to fail, we must check >>> - * that an entry was not already brought back from swap by a racing thread. >>> + * that an entry was not already brought back or split by a racing thread. >>> * >>> * Checking folio is not enough: by the time a swapcache folio is locked, it >>> * might be reused, and again be swapcache, using the same swap as before. >>> + * Returns the swap entry's order if it still presents, else returns -1. >>> */ >>> -static bool shmem_confirm_swap(struct address_space *mapping, >>> - pgoff_t index, swp_entry_t swap) >>> +static int shmem_swap_check_entry(struct address_space *mapping, pgoff_t index, >>> + swp_entry_t swap) >>> { >>> - return xa_load(&mapping->i_pages, index) == swp_to_radix_entry(swap); >>> + XA_STATE(xas, &mapping->i_pages, index); >>> + int ret = -1; >>> + void *entry; >>> + >>> + rcu_read_lock(); >>> + do { >>> + entry = xas_load(&xas); >>> + if (entry == swp_to_radix_entry(swap)) >>> + ret = xas_get_order(&xas); >>> + } while (xas_retry(&xas, entry)); >>> + rcu_read_unlock(); >>> + return ret; >>> } >>> >>> /* >>> @@ -2256,16 +2268,20 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index, >>> return -EIO; >>> >>> si = get_swap_device(swap); >>> - if (!si) { >>> - if (!shmem_confirm_swap(mapping, index, swap)) >>> + order = shmem_swap_check_entry(mapping, index, swap); >>> + if (unlikely(!si)) { >>> + if (order < 0) >>> return -EEXIST; >>> else >>> return -EINVAL; >>> } >>> + if (unlikely(order < 0)) { >>> + put_swap_device(si); >>> + return -EEXIST; >>> + } >> Can we re-arrange the code block as following: >> order = shmem_swap_check_entry(mapping, index, swap); >> if (unlikely(order < 0)) >> return -EEXIST; >> >> si = get_swap_device(swap); >> if (!si) { >> return -EINVAL; >> ... > > Hi, thanks for the suggestion. > > This may lead to a trivial higher chance of getting -EINVAL when it > should return -EEXIST, leading to user space errors. > > For example if this CPU get interrupted after `order = > shmem_swap_check_entry(mapping, index, swap);`, and another CPU > swapoff-ed the device. Next, we get `si = NULL` here, but the entry is > swapped in already, so it should return -EEXIST. Not -EINVAL. > > The chance is really low so it's kind of trivial, we can do a `goto > failed` if got (!si) here, but it will make the logic under `failed:` > more complex. So I'd prefer to not change the original behaviour, > which looks more correct. > Right, thanks for explanation. Reviewed-by: Kemeng Shi