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 A511AEE14D3 for ; Thu, 7 Sep 2023 09:39:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43A7E44017B; Thu, 7 Sep 2023 05:39:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C1988E000F; Thu, 7 Sep 2023 05:39:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 23BF344017B; Thu, 7 Sep 2023 05:39:54 -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 0D0E28E000F for ; Thu, 7 Sep 2023 05:39:54 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DADA9C01BD for ; Thu, 7 Sep 2023 09:39:53 +0000 (UTC) X-FDA: 81209304666.07.2705916 Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by imf11.hostedemail.com (Postfix) with ESMTP id 03CC54000B for ; Thu, 7 Sep 2023 09:39:51 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=SzvYcqO7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.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=1694079592; 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=gSn/skXMWf/xa0+iNC5/Gw93hjM5QOQeyldszIVaJcM=; b=3viPsH/jrdZ5bzjfVl2i/tyU+qUMZ8kQhZWfJuec+p9enrETF6QFsDVevFpNOrmOoTuDSF u/o4PTTx1Ai9ztT6oDOcak20sHmOutLOlohiZynDWzLuiaxmKnj6INnqnfNIfW1uQpsWI6 MPE564bHcpUunM5UjWn7odFA2BYHG3U= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=SzvYcqO7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.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=1694079592; a=rsa-sha256; cv=none; b=xKRgpIXGhOlOJWCUzKO1Sg6uhCC3HMYSEorkJb311HX9IwUDnNWf4dMWNhxnEEX4ru0bKy b16TKWVWYW2/VzprgHVR8d5T33yGtjqhjA+Qzh4NT1H+HR0RQnFIGWOK6ir5Asi7h+0nao yJ+dKjxFFhwNnyXR3mQCBemO9jkfMp0= Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-50098cc8967so1141244e87.1 for ; Thu, 07 Sep 2023 02:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694079590; x=1694684390; 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=gSn/skXMWf/xa0+iNC5/Gw93hjM5QOQeyldszIVaJcM=; b=SzvYcqO7l2zPcBriexdZJ1w2OaPdpWYQ+rYIQKZBBk3QY/G8ZHTIQ6pApHKrJPRFt1 4Mz8pCxGKjeT27g4ZBWTMJBSyDfPnOmPUdSde2GKRBJyxlFLfs2NmNi2XzzogpNQuSQI /pXtFy+aePNfVwm61IDXdVCra7R+KcaHJ1bu4+6itfgcLGGf+FcXeYP/ivJkk+mKKgYB wc2/Q1QCoYC3s3RrAk6wT4HC207+/7R2N17m8H4c291vEet0rp3l8jhH9ojTJ7mVZCEd 1ixIP+XhymRvh9rtbIfgk2ZIkPVO6qbMY6E614NSTLGcAiVlKMbqge5DDBeqFytZLqcD ZLXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694079590; x=1694684390; 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=gSn/skXMWf/xa0+iNC5/Gw93hjM5QOQeyldszIVaJcM=; b=j7b2pVmbVUbIQeZFIxc3x5OzYDn7RJV532qSmpmfDPPuISzlyq3y4/mM7ZGVBCtwbi ay8ftN+qHT8iBQc6uTqpGFgzXPJw5v49c1X/LdjVQHdG0HEYt+y7764imt9Lbk2/eMAH e737YxLuxrtL1ZNoARvxHu+m1IYsuyAIC++54JTBxhVen8cJidxp0S3c5q6pYKxvJ1ky EHgXMe1HUZ2aDgeg971hx7rgAV0Ed4arihmezvlTFRby2rl8JP0NWyqMV1caLtwv7ArJ lsICCnzExM5jYBMhKtT1iG6WplnF0QN9PWcoGFKT4uHDoDjyTv+TejtT6kKCSN19OYxH fBtg== X-Gm-Message-State: AOJu0YxZZ6hZc7bI5Xnr/VvtRBthmmgFUWD/zXnZtbTXvmpGCdzL4fvn /rJceqUr3otDTw4FEFEZxTQ= X-Google-Smtp-Source: AGHT+IG1t55SSsZ9IU41gZXp4fEBDaVSYmlggSt5r5GETk7wcr+KmFaGuKy5GVo7hA7HKyZxxIJlPQ== X-Received: by 2002:ac2:4db5:0:b0:500:b7dc:6c90 with SMTP id h21-20020ac24db5000000b00500b7dc6c90mr4108472lfe.36.1694079590034; Thu, 07 Sep 2023 02:39:50 -0700 (PDT) Received: from pc636 (host-90-235-20-237.mobileonline.telia.com. [90.235.20.237]) by smtp.gmail.com with ESMTPSA id w14-20020a05651204ce00b004fe2de20d88sm3082119lfq.232.2023.09.07.02.39.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Sep 2023 02:39:49 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Thu, 7 Sep 2023 11:39:46 +0200 To: Baoquan He Cc: "Uladzislau Rezki (Sony)" , k-hagio-ab@nec.com, lijiang@redhat.com, linux-mm@kvack.org, Andrew Morton , LKML , Lorenzo Stoakes , Christoph Hellwig , Matthew Wilcox , "Liam R . Howlett" , Dave Chinner , "Paul E . McKenney" , Joel Fernandes , Oleksiy Avramchenko , kexec@lists.infradead.org Subject: Re: [PATCH v2 4/9] mm: vmalloc: Remove global vmap_area_root rb-tree Message-ID: References: <20230829081142.3619-1-urezki@gmail.com> <20230829081142.3619-5-urezki@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 03CC54000B X-Stat-Signature: mt6z7rgnaiymaqqqg5hcqy8od4zjcjbo X-Rspam-User: X-HE-Tag: 1694079591-986783 X-HE-Meta: U2FsdGVkX19yGMNQwq+JYd7Iyx3r+bNTc7iZUooXc/u0zXPGjx37OBQrwgBnhq/K0F+11G8mO7flrk8dU0t0dGhJXSAHmngqH4Eu13ervdTS+KQXvzIccSvkWpFI3AyGMxOzjkqwhmIljVtnrrvuUXHCkURUakjRtyIrt0lWYVxu4N+DRzGjmKvte2TqkvWzF6WijK1MLxDuLOgzMKkRrEH9qHhtKVuTPMBTBohVai3tvRQFx+92HBBpHG6I/psIl4ewNrihy9K3wHcW/l6XkC0jSbJOZTl/3shL5ciIqvbe9/3o9dZBcbSYB4P6fY/w+JuD17EusXVWVWfNe+J1E61fPG6rXKSRi5Ryr6CsEpfOhdYeoyNy7RcXYdTepMTZnlIxAS/KSpG3TZK96+F6WOcWqnUBrf5xVZet/z7+zaEu4oqq9m9NHBe8XaTwhMW91v1E8lwQHNf6q2HLuKuvCbZzssVC+dZm5cvjCBZeOfjdW0xzilZLFj1wVD5Tp/QkaV8gqpqCbgnLJAhbasDsb/JH46Dzy8KmFid8mibk3su5k7yugjPsOuMhZBlZTH4IO8AUrUqpikgtY10qoTVn8PQnwYflMhpCkBGVJW1wuFekK8/R0x40MDJias8WeAjw8hK57ZXHgmZ86bMBmVwGP0VgbNHielzLg+j1nu0x+ex28i90L45FEpKgPNtfPLzpNPr1DqoO4pkdwaB9+Cq2z1CvSCY8OOHL2IisWfUWX+TIABtkWFY95YXtmDhRlXxrrGe2QXvu5ikgVxsR/W6LsXsDTPrhdPz7SON408Puff/a6yYnRa3h3KXUC+6k7F1CJGrEz3IWjHsxyDaSq/LdqTlEyepPgV9jfz+weO07JYf0qxzYZYSBtbMMkP4BMggzDUkR3Ml2NysLU+MdJYsRCOrhjHEEdNlKBWow1LQGAA0RgznvbpzKlSrsx/D0szLSvzPk79VW8b/J3bDVZnp 4PBkOqzj tG81RxuZaTL4PIx3tn/Q4Z2LE+mJ5XytMyFpLuxdtAPVDk3WsFVROXtdxRBsmFP/uxJb4TluMFpNLAUpZknP+Bk81+G21UK7I0m16X/QHvlcwz7nxVJcuvBKbLxHeUjRprlEQr/1JD+b1rSHtWAnj6yrKwTMyMn9cM7Ft+YO87x0KYp6RUHM3W5Llp6D51EXXLmBM+YK7vNAoCpXiIwxvwt8Nauh87x5wUoz6J//XLJ5UhGaoWl+vcp1ZeF6fAfXU77+4peD8xv5ykWvY1F12TW4P/K8iQnvcJ+l8awZmGj2cNxzG8fEYSTMvowzXgMb4bsnCCs72URdfgPvJZP3IKsS2mk1cUCs7wlaZDsrFd7eCBwzKROaLHDoxUEvryhyXqu5sprCnNuKreKmg0mCi30h7AeHog5vFgNicx+zZAhyx3uhGHzPka9CHCbs5gXA9/xdwPwijEXaeT2jUkgYrO5KoLLDuntgOb7ap 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: On Thu, Sep 07, 2023 at 10:17:39AM +0800, Baoquan He wrote: > Add Kazu and Lianbo to CC, and kexec mailing list > > On 08/29/23 at 10:11am, Uladzislau Rezki (Sony) wrote: > > Store allocated objects in a separate nodes. A va->va_start > > address is converted into a correct node where it should > > be placed and resided. An addr_to_node() function is used > > to do a proper address conversion to determine a node that > > contains a VA. > > > > Such approach balances VAs across nodes as a result an access > > becomes scalable. Number of nodes in a system depends on number > > of CPUs divided by two. The density factor in this case is 1/2. > > > > Please note: > > > > 1. As of now allocated VAs are bound to a node-0. It means the > > patch does not give any difference comparing with a current > > behavior; > > > > 2. The global vmap_area_lock, vmap_area_root are removed as there > > is no need in it anymore. The vmap_area_list is still kept and > > is _empty_. It is exported for a kexec only; > > I haven't taken a test, while accessing all nodes' busy tree to get > va of the lowest address could severely impact kcore reading efficiency > on system with many vmap nodes. People doing live debugging via > /proc/kcore will get a little surprise. > > > Empty vmap_area_list will break makedumpfile utility, Crash utility > could be impactd too. I checked makedumpfile code, it relys on > vmap_area_list to deduce the vmalloc_start value. > It is left part and i hope i fix it in v3. The problem here is we can not give an opportunity to access to vmap internals from outside. This is just not correct, i.e. you are not allowed to access the list directly. -- Uladzislau Rezki