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 04B00EE14D0 for ; Thu, 7 Sep 2023 09:40:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9428D44017E; Thu, 7 Sep 2023 05:40:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8CB178E000F; Thu, 7 Sep 2023 05:40:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7458344017E; Thu, 7 Sep 2023 05:40:43 -0400 (EDT) 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 5EDD78E000F for ; Thu, 7 Sep 2023 05:40:43 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 353581A01D9 for ; Thu, 7 Sep 2023 09:40:43 +0000 (UTC) X-FDA: 81209306766.24.02B210C Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf23.hostedemail.com (Postfix) with ESMTP id 049AA14001B for ; Thu, 7 Sep 2023 09:40:40 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=f67m96k9; spf=pass (imf23.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694079641; a=rsa-sha256; cv=none; b=GI6J5SmN6sAgX+vXo6Uabgl6876iBTMYDKVQpf2zOBbGz/cfMmaW9rKHVrfLMxlledpWCp wW2O9Sy2KqoQFGrUyBoxNwJc5J6xeytSZzKiQHMkp9SM+v5vIs8CSZK9YpDVY286JiA7lT wcDqnGQw7SAlRgi5XYFOzXN2z7v6O3k= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=f67m96k9; spf=pass (imf23.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=urezki@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=1694079641; 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=m2fdKFR8q9uEXLNSeU9tuN4gH8iEvFyeK5eSCmXl3rY=; b=a4bO4B2BYmpzImG2l2GblxB02HpMeHRfH4e464Gu/R0xB03LJ83d/xf8dE0t0XyGjz9nbw XBkmJh5LLrvxgTC5CMiAWlGYXkWxQYLxkOzMnIqT/VbERwR9hYYs3utG+cWme+RC5jji0f vvD+ZGLs1Pj/Y5T4t6zPb9gJpIM4KZk= Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-501ce655fcbso1132678e87.2 for ; Thu, 07 Sep 2023 02:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694079639; x=1694684439; 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=m2fdKFR8q9uEXLNSeU9tuN4gH8iEvFyeK5eSCmXl3rY=; b=f67m96k9WMlV+WbZFwYVm2dLbsBY6LuI5NFpGj6F+Mb15KC5DAfaU7aC+gbCR4CUS8 rZc71j0MtpAEfQhptyIFBwnp8Ac9UW1vp3a9+4gmrjltzkLpOr592OrKk0REl96xCARu 8cSA6/L3Efp3mtgjwf0glEuczcNVduNod4zdI1fxf8/3vXMi1UrOti5MZSlHAVUvwB+7 hvKhjg9kLExefFfF5zPxfHKHVC8RQL3A8UvIYNHrjezE51n9RT06k4yIfygS4s8pH2Zw 5TWLx98u5MQtBRdWu6WyeQF37hoTYfZfNo9A3DwIzZtrjldlCA3m/5P343VTsErrm8we FAyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694079639; x=1694684439; 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=m2fdKFR8q9uEXLNSeU9tuN4gH8iEvFyeK5eSCmXl3rY=; b=K12HM/TDsqvQdr6ssXcAQCIJacwN6Q1PgVQZ52LZl3yjCbmqt3SEvQkNDOY4vgyXUV kmUV288Wu/zn0vRMdPkR6vpWRDxoGy84mBVoeOIfXVHCU+67TlSnPVzR+BF3/Vo0/XvN 6rtf9yq1PkxNZhRh+glb2Wv/U1eOzROPbXh73p9/aGf6kGzHfHcLJHLwMANFeWVhezUI aFyoFMREafMhKLWOFD+OZe3PQS5fBQsww6ADziGTc+ybqbwIidt6lYPf/MbRw1+br8Bn bFx7Ua3pMUO2BAwwVYaynXtYJaXvScul9uay0M3IDAxmB91/6Eov5OK6BkLW76WJGlWj /+Mg== X-Gm-Message-State: AOJu0YwVolmhCR+pVAQQg89EKosF1X7TuCFjzT4vweO2D6HF/HRlz1FO +GVQWW1hWYCpvxKg8Semt9o= X-Google-Smtp-Source: AGHT+IGnVUxgJvZMlPBtKyIiXEz0zQ/L77txjqDYDTh1Sa3UGxaMrwFpLFqcHn1w07E0rmK4dukubA== X-Received: by 2002:ac2:52ab:0:b0:500:5d5c:ecc9 with SMTP id r11-20020ac252ab000000b005005d5cecc9mr4043445lfm.62.1694079639175; Thu, 07 Sep 2023 02:40:39 -0700 (PDT) Received: from pc636 (host-90-235-20-237.mobileonline.telia.com. [90.235.20.237]) by smtp.gmail.com with ESMTPSA id t16-20020a192d50000000b00501c6d78f11sm597800lft.298.2023.09.07.02.40.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Sep 2023 02:40:38 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Thu, 7 Sep 2023 11:40:36 +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: rspam08 X-Rspamd-Queue-Id: 049AA14001B X-Stat-Signature: drkyskeisrey6d3kti3swd3xzf1ttafq X-Rspam-User: X-HE-Tag: 1694079640-762072 X-HE-Meta: U2FsdGVkX19G6HFXdSp2LZ8rryafCvO3gc8m8+D9qwFbMIv/aZZEcYAFtsi4JizDNDecMtjebYYJv0vWxGTeqs05mtgR38KnmpKduf/n9cOmGT47UAq5rYI2Z/5V6M+igfm88PZew5H700x1fcD6YXZop+gRaIco8fmNr42eGLeO0pDLB1vbz2iwhgltYbm1GcD6rqaCdKpSJl/e2WLzkYs3L7K4IUCOrvbtcj+4ReEDjtl+5P540jT0o3KkZC9EaxSk+oqNA6Mwydq92ODWf/82f8ksK/2qzR/j2JoYhmuZ0nKpK/6K/kLhXgwGXsAxJzkH7ksvMbARr2zMsW2/uwWDdytnrKtGn0l4UTeRjAQeVtsoPLxETKOi2UQ+dP3QHU5pgM7uy7SFUfN6OyxArMz8c833ep0bvdqK2MOm1V4KUJwal/A0Q8XYOIxjX9wgOaftix0gxpHG4QDqzAIzQbLSJTFDv2QB9xSG/YppjmIR8xUNGWhqiUeJDqHuRZnMLHYL7FTnGsoCC7c3JKqOWm025e1+ZfjMeLwW1np6EDK+L5AhxLD5Ks0mFxTRhBGVGMM8IprcqeHzgc8N2VkI3EC9t1XaFC4XREZdXMY7AUKW0cpQ1J0CtR2zri0LYsLWG0L0+SKf0rRKeeD9JqMtue2FxFHHul/Zd8SjMxlDsV+MRHeWWj8gHusx72TyLnK7I8LFQ9dXSkF0RgDZ0UBMCMJFDNnQ3dSSXgaHoQ3OY3SMJ29zsiv4qxgWrM/1PcRyHUlhgMF0MraHyf5mZgObzWMEKdcmJWXvQ2HoHczbV7vI5r4SDaCd/a0IV2QxdFdcHFK1KEL9vxprOs/O/OAyu4vsYYYWX/qZERAQ6yTx8axsuMi2rOJ9+FyVNik9QwwNRqsAEVlUepCs6UCIcx2VXkLm6rnOdUqrkjjy6ET1O1vYAaIwWn+FjAyKZQzKwzK6otDgzzmSGNVaNb2KGzt KuelvGjv 4uK9Vc1UMdYLdSEHHtRJJN/PE2N4XXXKdBZxj/sWuzMc2/scdf0bAqMpOyaCYJU2fDfRRcWEVL8ta3jj5CjkfGldNFIIvrd2KZsdQMHGB9Xk5JZWEdRcGhma7JxhQFrYzUxR8Z1ah+LrKsTUKFyE9fYY7FQQoNnT/37RsQruvx7SLBNZZEwh/Sy2m585OsTJuhNEApg72prfMatiJAfYD557n4WIkMCZ1X9WpgU5k+wJIvwexPJfU1jAad0WpAEQjsl6GFlszHkHh1bH5k+iQMWmWScnQYChlhT/3LlFYXDlpr0m1Z0L9vF/wNJ2Fw6Yo6vqLAgKXNwZnvRyC6AiTyGcTZfBOOOLfpysE3DaDFjxiMX53TgxBcm1j1J+f4wT1y5gYmbwqiVLCKrkHNOELp9amkREGF3nLMLXvSrdb3H4L0Ao9TmoNKsBVyRn0ZcnE89nim70QJSo9F/9QWA3OO3LxWgHzFrOGXJREMqdQyyOfLHPf2Nm46FXmNzllJ2/FBCMA 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 05:38:07PM +0800, Baoquan He wrote: > On 09/07/23 at 10:17am, 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. > > Except of the empty vmap_area_list, this patch looks good to me. > > We may need think of another way to export the vmalloc_start value or > deduce it in makedumpfile/Crash utility. And then remove the useless > vmap_area_list. I am not sure if we should remove vmap_area_list in this > patch because the empty value will cause breakage anyway. Otherwise, > > Reviewed-by: Baoquan He > Thanks for the review! -- Uladzislau Rezki