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 2E700C369AB for ; Tue, 15 Apr 2025 15:25:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 05B02280003; Tue, 15 Apr 2025 11:25:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 00ACC280001; Tue, 15 Apr 2025 11:25:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E1373280003; Tue, 15 Apr 2025 11:25:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C431A280001 for ; Tue, 15 Apr 2025 11:25:46 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id AA025120EE3 for ; Tue, 15 Apr 2025 15:25:46 +0000 (UTC) X-FDA: 83336653092.05.78E7479 Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by imf09.hostedemail.com (Postfix) with ESMTP id 96FE514000F for ; Tue, 15 Apr 2025 15:25:44 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Rx3mnEpI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744730744; a=rsa-sha256; cv=none; b=eHAsxKwwSpoQx6TjX2TJ5sFwwKaCrN8Bs/wJ6XqmPcxXboYlecd+3Ms/xUA5g4MqR0E9uC MkSqHzZLoLCtBmuZwqFuJBSxvPpzLOEltI4Q5KjZ451wEzy0igLjNQm7HV9OniW5oQZmBp sEednB67E8fbWqEiDnQAkFXOOxxtFbM= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Rx3mnEpI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744730744; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=caCzhh025qvO/bkRjuZEttwiNhcUgLhjeVjQBL91Qmk=; b=3VuZTQKN3eZpH5I8bihXFsCFy4qEOvSoA73k3O+50FHG8an4nX8tDacXjWx6bdqti3P0c6 Lw1GWcp0tz+OAgQf0zF9cjN06+GSzppVd9CG/Jrimq01jsimEWKP8ZKHQ67MbDCD+Q8iax bUIOlZFWT6wLlRPy8z1zLfmWMtI2pgc= Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-54c0fa6d455so6631985e87.1 for ; Tue, 15 Apr 2025 08:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744730742; x=1745335542; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=caCzhh025qvO/bkRjuZEttwiNhcUgLhjeVjQBL91Qmk=; b=Rx3mnEpIuAR/AA82JiK0GGQbzr/bQeYtUaB+iawebtif+ZNph7bc8A68t44Is+wpqf H5RPdVy8XNvKHgkf09l8ODXit5b058DbYi7I54LvNGMSuReWZ2moxcqIHct7w3YB4peV pUt1VNp9eP9Ogg+HOVfWK2HOqZoqLcfKQxFGBkrI4tfcqu0JxwZdK7v2rS9sqyOdDiIL sK9SqSM6bZkTLXD1DpzL7lI67YY+P0sMgB18h7MTuFoy6S/UMqMBE5L55mRXk18ALUw5 ifMXgj7Ds/dNhWott+VquoOnRc3I46genC4T3mIUwVaMAcSgM8kDz2hF7ppLQT0wtvcE TFPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744730743; x=1745335543; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=caCzhh025qvO/bkRjuZEttwiNhcUgLhjeVjQBL91Qmk=; b=hKQIFJZyCDInlLxpcJ2Pzn5uqgiidplTnErdvn78b8sGdDRIGtVVGzEJZxUUpzXx3b EgvB15eF5OnaWpTZ9dV53G+sgTVpzy1Nj/+7sb25JgApPbDSzRmTVOWvpJ7XDp4CbS+w 60PyOD+Jb9WAGVmMGQ6Nk+zX/0KTkgshbQdB6+L/v0TCjGA1XYsR4JtmRUUDijeNx8r0 TPcJDajdSe6oO9+ajL8DsmyXxGlx9oNnqqFiYy9OwtTIXFMa0gh+jQXwQDgTZmBolqUr IA/ui8B2w/3lB6NtSI8DdLWUbwIJbx6q4vflXyvzV7VcEfwlFJnIJjneY7rqwac/iThA 47RA== X-Gm-Message-State: AOJu0YzzXFj8uMBgGsC9fu6i7szZwirgs+teHL/bqVBEbedgfD8wLE5C IuWFOKU7usNfbVbP4SJZ0oiAfB1+dLesdXDtoOPDF64Mim/1CG4w X-Gm-Gg: ASbGncstLDkKdLIq/+DDWtVLVRZISUC6qZqQyViZk47dy3EpP3wtcxMG+VbWvummWVG Z8ZyCPEqceXJ5q0ctIQlTnUkqUhcD43HjbeF0x/1XpVAyTbo1aOpidLUov4Q5ieMWdxhjn/31wz dReg+Gio8k+3StbbUPdJ1eAdJ4E1DHxlARd+syA3Y/YuiOpasN+Y7Wlu5Vr45FNqDrHh/dZgSc1 dtA1IOXPTSlaN4f+lxBtBoFYTagKGAIoAZaBlWHb3jySNBetAjyvOFcp+RGL+C5rpIKGOAEbcse hOTEN7M8a1aCOaY16G50sloAP9gSrk/fOmSjicXPS0a/DdWD/Q/MsBwPGqyxtxufPusV X-Google-Smtp-Source: AGHT+IHtTzOVSFETAUI11D2B7sQ8XlHAucdVyO3RfPAl6V4IVSz8VSSholwW0WzIMUxqTf4V++GMbA== X-Received: by 2002:a05:6512:2385:b0:549:903a:1c2 with SMTP id 2adb3069b0e04-54d452d98bbmr4705640e87.49.1744730742180; Tue, 15 Apr 2025 08:25:42 -0700 (PDT) Received: from pc636 (host-90-233-217-52.mobileonline.telia.com. [90.233.217.52]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-54d3d51ffa1sm1426337e87.228.2025.04.15.08.25.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Apr 2025 08:25:41 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 15 Apr 2025 17:25:39 +0200 To: Baoquan He Cc: linux-mm@kvack.org, akpm@linux-foundation.org, urezki@gmail.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/5] mm/vmalloc.c: find the vmap of vmap_nodes in reverse order Message-ID: References: <20250415023952.27850-1-bhe@redhat.com> <20250415023952.27850-3-bhe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250415023952.27850-3-bhe@redhat.com> X-Rspam-User: X-Rspamd-Queue-Id: 96FE514000F X-Rspamd-Server: rspam04 X-Stat-Signature: enmw3nqiieuchj63iz9dj5cpibdpaa8h X-HE-Tag: 1744730744-395620 X-HE-Meta: U2FsdGVkX1/bc1Fr6k+65iIWHlACHPh9Wz0nlVU4bTSyTHBBDyZGF8kKA931k4B2GdOyseb93fnPTy9kbldHkd3XawE+uppmcFdi832SVkcxDWOzDEpAP1g8H4PUJJAyMOM/BIB/x5b6po3yyM/3T0ra4XCZujc0/MG7TEFI8kdfLeggyV6NE76BkfJK0KOZxzabjUrkl9gkhUAWd+iZ2isrd5CYLKrn3n4YzQxdLwC8WXYovd7DoPSoTyQgvbAuuZhDE6Vk9filpN+oki0yPFvwjmV49JV/4bmLtVu4eWO9VNaDWIp0pUlNylD2jTqGKtp22gM+opftiN7gSL7p0LDue0btoatta3wnhgoclZuOw4BSUfgcJCu7ocIJSP6U/TYQNb/wli/mxQqs43pKeHOoZYCNW6QnUj9ZDaJQhvXaIVn9yAQ01xf6/E7HWfeWKuvXoiMxVf6qzVgzoBQGnwEdGRpiA8jCImzh6Yg+v1WvDeZxeoB3nXtF/gHRL/IWssByjYl8cOAtKqCu5YjIqO8+6GTuPbQsyPJ/lb+FQdypbekZtLb9mF9S5nccKYCt+FYpjbkjh6i1GlZ1J2xDy1UXmIbQ0IU7VlZheWSyoMkzzJMuErKbnp1tco5HINiBLdWWdvPWISiB3N+mIkBxHyiGFBc7swwgNJRXLW8xs58dNSf/yXPLf2jXSsCn4raCO/HETnRA/EtbKHtq8E6ZTfFkiKokEWOrqnZ0pH3AgqHD8hFmyWQ9uAne27w1xFlv8M9byg1lnJpFG1oiSXrwBlxj90jmgVnyslR00s5xS7lXp/RvJorTXB6Dnj3hLEDk0Ns2d6SlPijdBRvKyR9bCSb1KiGxkeM7O3cWbtSeEUuSoD495cH65HIXcES1Fbigy12KxuDBiAnuSnbsINDahTjlfTUJ4+RViKiQKW/PI7+ECCN1XEX3zKzSb4lgPcsEsso/P267tJwgx9YX9mc faWnAnN8 OQQ6GaFJ6LEl179jb7ytg2CRfpbuD10ovdTyo+GuqBzmW9wIuUbSjv62mPTnnah0Bd5OJA48wxIHMGAf3Yq4HRmZLV1LW2iXHbaoMDT21SHoXfL5blPz/A6WSC8iKE0zrhwExyXSgQlRzW47B9cVATjTFdgDN5lSKTgD/YMu8foHSSx161Zzc4Jl9BA3rHULwYRfz9o6zzpg8BHXcDMKJtTBb0lqLrzZSfnyU+gJEVtXsxOrHBjBaTRP7AxVqR5oiN9D0SsfTZm45Ydu/V1sMoLECxvTJOT9hvbXBs/8E3a0jq2tzByC/mBMNczoi+oMCYE5YNuoTBiOvxe7y4PaxcVUy/aocKRavNGF/GaW37qA7FzhGFhXHkCcuq3T5QDSjI0PTNj0lMGa+fT5nYUHW5d9gYeYDqFK6eFbQIaWG/v2mmwuj0qNpKkqYHs4PSQ20xui64NuEkbYVAouiaB80N0hgcAEKOmM8Uorhvzc1UcaWQMI= 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 Tue, Apr 15, 2025 at 10:39:49AM +0800, Baoquan He wrote: > When finding VA in vn->busy, if VA spans several zones and the passed > addr is not the same as va->va_start, we should scan the vn in reverse > odrdr because the starting address of VA must be smaller than the passed > addr if it really resides in the VA. > > E.g on a system nr_vmap_nodes=100, > > <----va----> > -|-----|-----|-----|-----|-----|-----|-----|-----|-----|- > ... n-1 n n+1 n+2 ... 100 0 1 > > VA resides in node 'n' whereas it spans 'n', 'n+1' and 'n+2'. If passed > addr is within 'n+2', we should try nodes backwards on 'n+1' and 'n', > then succeed very soon. > > Meanwhile we still need loop around because VA could spans node from 'n' > to node 100, node 0, node 1. > > Anyway, changing to find in reverse order can improve efficiency on > many CPUs system. > > Signed-off-by: Baoquan He > --- > mm/vmalloc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index aca1905d3397..488d69b56765 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2436,7 +2436,7 @@ struct vmap_area *find_vmap_area(unsigned long addr) > > if (va) > return va; > - } while ((i = (i + 1) % nr_vmap_nodes) != j); > + } while ((i = (i + nr_vmap_nodes - 1) % nr_vmap_nodes) != j); > > return NULL; > } > @@ -2462,7 +2462,7 @@ static struct vmap_area *find_unlink_vmap_area(unsigned long addr) > > if (va) > return va; > - } while ((i = (i + 1) % nr_vmap_nodes) != j); > + } while ((i = (i + nr_vmap_nodes - 1) % nr_vmap_nodes) != j); > > return NULL; > } > -- > 2.41.0 > It depends. Consider a below situation: addr | VA V <------------> <---|---|---|---|---|---|---|---> 0 1 2 3 0 1 2 3 basically it matters how big VA and how many nodes it spans. But i agree that an assumption to reverse back is more convinced in most cases. Reviewed-by: Uladzislau Rezki (Sony) -- Uladzislau Rezki