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 05043C54E49 for ; Fri, 23 Feb 2024 10:26:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D482C6B0071; Fri, 23 Feb 2024 05:26:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CF9BB6B0072; Fri, 23 Feb 2024 05:26:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B98AD6B0074; Fri, 23 Feb 2024 05:26:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A6BDD6B0071 for ; Fri, 23 Feb 2024 05:26:50 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 17686161088 for ; Fri, 23 Feb 2024 10:26:50 +0000 (UTC) X-FDA: 81822690180.11.7D1BAE3 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf26.hostedemail.com (Postfix) with ESMTP id 42549140007 for ; Fri, 23 Feb 2024 10:26:48 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JxnfS2Id; spf=pass (imf26.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708684008; 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=L7ZgeQyHFYB3/81Utje95XfrXMuh6+qbwX5x3w+wZyo=; b=Q6NBepffdWX/zzNESvyEgCzteLhwkVyddMR+ip/aabWJ3vKoQU0cOFCL8jd2PXYm0eLtNp aqPhPI4vgZ/fu495jUAOMLREuwJ0Q9g3wO56Bx3fASDoKwC52nGchDcEHwO2L0S/FLzHXe z1T2cx1EQ1wq5gKt7FBlm9rC5brzdGA= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JxnfS2Id; spf=pass (imf26.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708684008; a=rsa-sha256; cv=none; b=T+h9N/Zzt5kFA1GHoPBiqZGGlsErmfwGxZ2g5Xf4+yRCuQE8vFCMMV6uge42fRMFOdLYtO eC7dcGq6Pb89SYqEoXDKJVry3zM/Ph+1Dal14aReHG0C3Ckx8ukQcBR4i2Je7anbq+YDxw 5TXz3/07TmYm8y+L7GweLcbR9O7LSjs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1708684007; h=from:from: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=L7ZgeQyHFYB3/81Utje95XfrXMuh6+qbwX5x3w+wZyo=; b=JxnfS2IdSuO+THxnOyTtK5hPgaVIQo/1jB7OnXddJ80RNvQBvO8UYBt9BRWQfycMWxxXJy iEM2gB9v9fGV1fDgoug0bkXEsS0xnB6GXuiGmMe3UmlDep2q3/Yi/rAD3OoNRQclctZ/bQ CeAnFAsYYqmnj73+FPqYEVVqHyZpcXY= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-389-lxyuidWzPfia3GjyArznAA-1; Fri, 23 Feb 2024 05:26:42 -0500 X-MC-Unique: lxyuidWzPfia3GjyArznAA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D92841C05191; Fri, 23 Feb 2024 10:26:41 +0000 (UTC) Received: from localhost (unknown [10.72.116.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E561D112132A; Fri, 23 Feb 2024 10:26:40 +0000 (UTC) Date: Fri, 23 Feb 2024 18:26:37 +0800 From: Baoquan He To: Uladzislau Rezki Cc: Pedro Falcato , Matthew Wilcox , Mel Gorman , kirill.shutemov@linux.intel.com, Vishal Moola , Andrew Morton , LKML , Lorenzo Stoakes , Christoph Hellwig , "Liam R . Howlett" , Dave Chinner , "Paul E . McKenney" , Joel Fernandes , Oleksiy Avramchenko , linux-mm@kvack.org Subject: Re: [PATCH v3 00/11] Mitigate a vmap lock contention v3 Message-ID: References: <20240102184633.748113-1-urezki@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 X-Rspamd-Queue-Id: 42549140007 X-Rspam-User: X-Stat-Signature: sng59b7mgepg5tckkp1qrjasmz91fmzn X-Rspamd-Server: rspam01 X-HE-Tag: 1708684008-942107 X-HE-Meta: U2FsdGVkX1+TwZ85MHWPXItStEzu2//M26ZDG12meV5YeMceMzulwt70yLnCqaLnAw5FCNmfjw7Zo6XkjnQHBz15w/05VmW0dhtmxHz52ssrNuZUZPNNSIgTcFKjr0GB/hPXpPxqEyrTJThQHQ14qyKLZlqJVTIQofiII/Sr/G4h4l1tfR6/Ve9buwVU4nyCO0CBooRh6uT6q/fGsSs6PeTIwIcVJ6pC3eoKoo3vo5XagvBmBUuiyGoU9lI7+rLDMJOaSR9rsCJYWJcp3IBNR6tD3HG7pWVTBqLaGB0YSGvbkX8znY7l2lGi+iYeKKAc1NIW1z1AfofnX02vzsPeSoSOgGAfwVucBghmYHl9NU8ixad5egeUXbXf0WxTKtPMM7MnrryS08/y4g+ML0P6kIMLXy1xKJRcwOb9y4Qp/tNWiF+QDVAhKc2SZsJMJt9JctGkh704XpiaRtKyESH6hi/IgbS4BwB3Kdrk64ZmrBbvzn88umucEW+THRaUi4eXwVGQS4UCORssxkgFwTDsbyRqz8vyegp6wfGi2BpU8lEN1/Q6Xdf69kEhzOUkqsafJ6HyVWObRPg+u8L5pyOA8BZknuB0Ki47KQ5LhqBdM7x0KwR0gQN6bihIJ7lVd1erzAzKTib9rcRoQIzHdCwWnA7T1Wv/7iH5EP1ID5lzNJDywwalQhgi6cUVulflhrXwkt4XpzIQGKeTMpZtI3S1dbYeMzuGmiRp7a61xQhS71S9jDKxsySkmYbCnGA1un60Zm4Sblh1xuyV8I2Dx/aEOvSAMLjmJy0eJdh7gFFEIqvlDkevimJWj0JQbk3qNpdvDhRuDzYyl78E/J3Oi3Lv8vC2uqx9LF/SBOrPQwiwbPJZU9ojHZ7CG/Dn3i1842LoZm78WEiOa0cBfcueuNwOT37Ztx6mW+xxVY85JGTMQOE6RHYv2w57/DGIx61wFhDm8ZOlBRSnw+6IhBSuEXF R1Abfy7t EOmFMEbQ6w8zq5IAkT+su2oqD74/6yJ3BmlezpX6Di4zCqhjFwlF8UBb30ToziTntcHahaz5Odcw/s80vWtMW8bD947yorq/Wu9m6KM0JMPY4noYpOwww8XassctOOdO42kv5og23QC7uBSh4VTd5bRiRqYvAbB6+N0iCVae2X6Wy6RZ3ojp/PGl7VFNo0oXJ1y6DhlYc7WUMWQUzDB3bwt3OrbVqG58pVvz7zpj8DSQwNNKhf9aw3Fo9K4XnwmYl3MKdGnJhr7fF4V8LIVswLxF6jI6BuqdSw7iwXh7LXq04mXE= 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 02/23/24 at 10:34am, Uladzislau Rezki wrote: > On Thu, Feb 22, 2024 at 11:15:59PM +0000, Pedro Falcato wrote: > > Hi, > > > > On Thu, Feb 22, 2024 at 8:35 AM Uladzislau Rezki wrote: > > > > > > Hello, Folk! > > > > > >[...] > > > pagetable_alloc - gets increased as soon as a higher pressure is applied by > > > increasing number of workers. Running same number of jobs on a next run > > > does not increase it and stays on same level as on previous. > > > > > > /** > > > * pagetable_alloc - Allocate pagetables > > > * @gfp: GFP flags > > > * @order: desired pagetable order > > > * > > > * pagetable_alloc allocates memory for page tables as well as a page table > > > * descriptor to describe that memory. > > > * > > > * Return: The ptdesc describing the allocated page tables. > > > */ > > > static inline struct ptdesc *pagetable_alloc(gfp_t gfp, unsigned int order) > > > { > > > struct page *page = alloc_pages(gfp | __GFP_COMP, order); > > > > > > return page_ptdesc(page); > > > } > > > > > > Could you please comment on it? Or do you have any thought? Is it expected? > > > Is a page-table ever shrink? > > > > It's my understanding that the vunmap_range helpers don't actively > > free page tables, they just clear PTEs. munmap does free them in > > mmap.c:free_pgtables, maybe something could be worked up for vmalloc > > too. > > > Right. I see that for a user space, pgtables are removed. There was a > work on it. > > > > > I would not be surprised if the memory increase you're seeing is more > > or less correlated to the maximum vmalloc footprint throughout the > > whole test. > > > Yes, the vmalloc footprint follows the memory usage. Some uses cases > map lot of memory. The 'nr_threads=256' testing may be too radical. I took the test on a bare metal machine as below, it's still running and hang there after 30 minutes. I did this after system boot. I am looking for other machines with more processors. [root@dell-r640-068 ~]# nproc 64 [root@dell-r640-068 ~]# free -h total used free shared buff/cache available Mem: 187Gi 18Gi 169Gi 12Mi 262Mi 168Gi Swap: 4.0Gi 0B 4.0Gi [root@dell-r640-068 ~]# [root@dell-r640-068 linux]# tools/testing/selftests/mm/test_vmalloc.sh run_test_mask=127 nr_threads=256 Run the test with following parameters: run_test_mask=127 nr_threads=256