From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793365828; b=UvZvnOijsYg3avhmkJOdCMKnqiqstrb8C7UD4KY8G865xLFreUpdZN9KZNyLM5hvxifM F4k2Sshdjl36KAJDATcVxtx+j8IQ3tTpB5XeKmDFpiU6yx/xwOhXRerVM/Y4J4D9rHb65 aF7zt3OTXDOuJfWBVyKDx7EqiB7soAQY3RKz1BJfQtBhCR9jMRfXc5t6NouEUFS1dy4bK uupxW0JyRRAlqAZFmZJ5aQ60pu+YW8ebxqG7m0iThoYLxIm2CzND/XmvbzkqyEchbxzn8 PdcMrOrmZwIU6eXoaBHDQKuYuyQxbfUDPxXXiGsKgTWs8/AJ3p++oPUcFXLlD13nnkA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793365828; h=Received:DKIM-Signature:Received:Received:X-ME-Sender: X-ME-Proxy-Cause:X-ME-Proxy:Feedback-ID:Received:X-Mailer: MIME-Version:X-ThreadId:Date:From:To:Cc:Message-Id:In-Reply-To: References:Subject:Content-Type:Content-Transfer-Encoding; bh=BIsmxaqlcIiqqe+DfpItRAhgOJbkWsY0ZSYuASH2dgo=; b=Gi1e+UP+DrnLNc+jCWy4G0zV3ANTukG/82EFpIKWWhjNc6HS/Ldk38lFC9fbxciyU+GI h75kOFWQZ+pKlvhACacgwHd3T7szmRvZysR379ukbhO5LuVBf+3XRzHTcaVJUZX5hWE7f XIGas09L6ugCiYWT3f/1psPl8ceqzbH9hyQYDXykzKmLp48RJNA27WxEWeHJEA4heHWPk psnh2zraYZ5YUn7F7bau7uV2Mjx4Jui+zdXXwJgvL3BTagpmMsq0AcVvPQjttxBNgz53g Vh6Bg7W1BAH0tOFf5BvA0X0/m4vu08WJ/4opWHhqvRohJ2+fcjxxWCNGIWk8cANJU1g== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=aE+UcR4O; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BABBF606A31A for ; Fri, 30 Oct 2026 13:10:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=aE+UcR4O Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E5611F0093A; Fri, 30 Oct 2026 13:10:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793365827; bh=BIsmxaqlcIiqqe+DfpItRAhgOJbkWsY0ZSYuASH2dgo=; h=Date:From:To:Cc:In-Reply-To:References:Subject; b=aE+UcR4OtmI1gsAuleOjFb68pLXXLXkRQbAWvngo171T2MUUuwjy+lrcz2fa900Oa 4jrYfKABe2JsUQNDDMr8LHMydxA2OR4eFUP0n+okjO+fCYNkr2t0oFDX3OZbWNsHkc 9FOki2qP8o1578DoVS6j4Ha2l9nKWXo/PwQLeofhbAptMNLznIZcalKf4CfY+TsEU5 ko938kjuwV+SzeAc1oCkdQMWrUvfCXsLdHLlXHlbAX4d2Qvq1JA8oZU/MBsn4zu9iH /mYszUAhgaZ3QvOiktJYjo8pq2d+/cDPxcPeXZHq7P6jbizyjM3/JsXTfeJejutH0+ QVqpbytwntPyg== Received: from stl-compute-04.internal (stl-compute-04.internal [10.204.2.64]) by mailfauth.stl.internal (Postfix) with ESMTP id B22B6780043; Fri, 30 Oct 2026 09:10:26 -0400 (EDT) Received: from stl-imap-13 ([10.204.2.104]) by stl-compute-04.internal (MEProxy); Fri, 30 Oct 2026 09:10:26 -0400 X-ME-Sender: X-ME-Proxy-Cause: dmFkZTGh/6azztQX4EjOpOWsP9cU87M/GO2aoMRhBpjxyvA9Mgxud2UfYibhs/CNwlNrxR OVYhQ00dRta7xjyTz8NtYoTm7ScvixKhrCgmB14JzOz0EI/mP6fEi8NWTuMHhrcDaZeBk1 YaQTwyUEgXvrrCojrJE/qHFnsqVSnKBrUgjzGmjfEQsz/3lIybZUkOsNLIPE9CqfqBx7Ah c24qnXX2j9fLPh5cewjKYtSEE+5zOGLldi7n9WyLyT2lALzgx/t2uBwk6YlpgQtoGaFAlv yB2TdRcPZQLT6XQVgCOGmWsKCe+r6lBRqzeLlPt7JfBlWSjnTHhGNl3PrxEWFRylHy3lYf kpptfFm+LkbmYdnqv7oT9qRe6teuGi7QOqfk5YudV2k5/qHerwrD5mfpc1QxohxNmdHQ67 yj8Rz7kBIydzzYNKrzYQKqbQXg0kSF8IHV2N8ZkxHRhLt4+XOPrRrgms7SZ9do1Qu2fOEf 7gKxf9P9fbZ/DgTar35vJ2bvnTZ317N7Y8UTtBnGUltw+RKrdEC4+6AQZMWYfuqSibj6JM 96wE3O2w5if218SI9BPq+AC04w4C8BL1PIZ2E3PLHYgJEITmt5yhSABPu0OlnexaD6/LLQ jwjzjRs+epVjfmBA0tpujtP4JNG/zdq0IHpXR7m2kfDQlL4Dtjw0AhljJPGg X-ME-Proxy: Feedback-ID: iccae4b50:Fastmail Received: by mailuser.stl.internal (Postfix, from userid 501) id 59AA0F6007F; Fri, 30 Oct 2026 09:10:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 X-ThreadId: Aey4jMk1dEgs Date: Fri, 30 Oct 2026 09:10:05 -0400 From: "Chris Mason" To: "Muhammad Usama Anjum" , "David Hildenbrand (Arm)" , "Andrew Morton" , "Johannes Weiner" , "Michal Hocko" , "Qi Zheng" , "Shakeel Butt" , "Lorenzo Stoakes (ARM)" , "Kairui Song" , "Barry Song" , "Axel Rasmussen" , "Yuanchu Xie" , "Wei Xu" , "Baoquan He" , "Baolin Wang" , "Liam R. Howlett" , "Vlastimil Babka" , "Mike Rapoport" , "Suren Baghdasaryan" , "Michal Hocko" , "Kees Cook" , "Peter Zijlstra" , "Jann Horn" , "Pedro Falcato" , "Hugh Dickins" , "Pasha Tatashin" , "Pratyush Yadav" , "Matthew Wilcox" , "Jan Kara" , "Zi Yan" , "Lance Yang" , "Rik van Riel" , "Harry Yoo" , "Alistair Popple" , "Nico Pache" , "Ryan Roberts" , "Dev Jain" , "Usama Arif" , "Kiryl Shutsemau" , "Matthew Brost" , "John Hubbard" , "Peter Xu" , "Will Deacon" , "Aneesh Kumar K.V" , "Nick Piggin" , "Oscar Salvador" , "Minchan Kim" , "Muchun Song" , "Xu Xin" , "Chengming Zhou" , "Chris Li" , "Kemeng Shi" , "Nhat Pham" , "Youngjun Park" , "Gregory Price" , "Joshua Hahn" , "Rakie Kim" , "Ying Huang" , "Jason Gunthorpe" Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-cxl@vger.kernel.org, "Josef Bacik" , stable@vger.kernel.org, "Thadeu Lima de Souza Cascardo" , "Mani Tofigh" , "Samiullah Khawaja" Message-Id: In-Reply-To: References: <20261029-fixes_core-v2-0-a64ce7f83abb@kernel.org> <2f23dafc-43a5-47c9-a819-e696cda6fd44@arm.com> Subject: Re: [PATCH v2 00/47] mm: various (urgent?) fixes Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, Oct 30, 2026, at 8:12 AM, Muhammad Usama Anjum wrote: > On 30/10/2026 11:35 am, David Hildenbrand (Arm) wrote: >> On 10/30/26 12:19, Muhammad Usama Anjum wrote: >>> On 29/10/2026 8:32 pm, David Hildenbrand (Arm) wrote: >>>> See v1 on details. TL;DR various fixes :) >>>> >>>> Thanks to everyone for the review! Hoping I can get some more? :) >>>> >>>> I am planning on picking these myself, moving them to linux-next fairly >>>> soon through mm/core.git. >>>> >>>> --- >>>> Changes in v2: >>>> - "mm/memfd: check for real shmem inodes before accessing shmem state" >>>> - Call it inode_is_shmem >>>> - "mm/truncate: look again if a folio left the mapping" >>>> - Different fix for truncate_inode_pages_range >>>> - Adjust description >>>> - "mm/huge_memory: fix zapping migration entries for device-private THPs" >>>> - Move handling in zap_deposited_table >>>> - "mm/mmu_gather: fix flushing ranges with 4 GiB or larger" >>>> - Adjust description" >>>> - "mm/huge_memory: split huge PUDs when adjusting VMA boundaries" >>>> - Drop split_pud check >>>> - Link to v1: https://patch.msgid.link/20261027-fixes_core-v1-0-6f74bec9a5bb@kernel.org >>> I ran Fastpath, a Linux kernel performance benchmarking framework, on >>> this series against mm-stable on aws-m7g.metal. (I) and (R) indicate >>> statistically significant improvements and regressions, respectively. >>> The results show 10 improvements and 1 regression. Other, unmarked >>> percentage changes can be ignored as statistically insignificant. Hence: >>> >>> Tested-by: Muhammad Usama Anjum >> >> >> Thanks for the results. IIUC it's schbench that shows a possible regression. >> >> I would expect that no changes here really affect performance at all (neither >> positively nor negatively). >> >> "mm/huge_memory: fix list corruption when deferred_split_scan() races with >> deferred_split_folio()" fixes locking, but I wouldn't assume that this matters >> at all for this benchmark. >> >> "fork: take mmap_lock before copying mm_struct" changes locking, but I also fail >> to see how that would affect the benchmark. >> >> Maybe some code layout changes just affect some benchmark on some machines? >> Because already seeing 10 improvements makes me wonder how that could possibly be. >> >> So I'll move forward with these fixes for now and see if we get more reports and >> could identify actual problematic commits. > > Yes, these improvements/regression might be because of code movement and how it > has affected the run time performance. Most importantly, these results show that > there isn't any drastic affect on performance. These fixes are good to go. This schbench configuration is going to be really sensitive to process placement, and it should be doing all of its memory allocations up front. I haven't done many schbench runs on this type of hardware, but I'd agree this result shouldn't indicate a bigger lurking regression anywhere. -chris