From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 84F9529A9 for ; Thu, 12 Dec 2024 00:13:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733962413; cv=none; b=Hr6i6mcDwVkK6qbaJgYCA5DBsODgtDoRg6GKMfogFvUs+XcNmcr3NMzTECelNluKcmXF7WRmrGcXHiBIZ34QiA1QOwR0fnOU9Z0hI2AoSY+9O6Af2wB3IGBmd5lvzmU8FhN84tTuhEPVhlhQ77wlAE6zP3rMC9kuvfDOz1xcT28= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733962413; c=relaxed/simple; bh=4tBjqPXEk1wTI3GI2h37EOHLmPMSjTibz8Bh5MKSOus=; h=Date:To:From:Subject:Message-Id; b=QclFNYXVNXKHVsOVMBqmHxKkpG9EIWTExXuHTpM1XTH5IQJkL6ycvf0ooC6Fo/I2kLbzfLQHTp7D+cFrRyPzsn8Qn4o7b9r7s2vpVCUl56ZIMp3baTD8R4OMX/npEGI+77kedgxGaKx4ExeIgsfAYPG+PG/YE6aZzlRbNx7Bvy4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=dxPZzIWR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="dxPZzIWR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 55DCAC4CED2; Thu, 12 Dec 2024 00:13:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1733962413; bh=4tBjqPXEk1wTI3GI2h37EOHLmPMSjTibz8Bh5MKSOus=; h=Date:To:From:Subject:From; b=dxPZzIWRzmRvS3LEvfzJtZ+eXl4O94t8j2y3VwF1FYcgA2PCxtBOjRprDY1/U8AQh 2VsiPJCIRiECSx7siPOCwlsqcvHomh04H2JZ3EICFEXZlw6mV5CVtJmNpFMxdDZeHW FCto4jSZyVlSofCRD3w2/NiiYEeF8JMCFrMZqKQc= Date: Wed, 11 Dec 2024 16:13:32 -0800 To: mm-commits@vger.kernel.org,ysato@users.sourceforge.jp,yang@os.amperecomputing.com,vbabka@suse.cz,tsbogend@alpha.franken.de,tglx@linutronix.de,riel@surriel.com,minchan@kernel.org,linux@armlinux.org.uk,leitao@debian.org,jcmvbkbc@gmail.com,jason.andryuk@amd.com,James.Bottomley@HansenPartnership.com,glaubitz@physik.fu-berlin.de,david@redhat.com,davem@davemloft.net,dave.hansen@linux.intel.com,dalias@libc.org,chris@zankel.net,bp@alien8.de,bhelgaas@google.com,andreas@gaisler.com,kaleshsingh@google.com,akpm@linux-foundation.org From: Andrew Morton Subject: + mm-respect-mmap-hint-before-thp-alignment-if-allocation-is-possible.patch added to mm-unstable branch Message-Id: <20241212001333.55DCAC4CED2@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The patch titled Subject: mm: respect mmap hint before THP alignment if allocation is possible has been added to the -mm mm-unstable branch. Its filename is mm-respect-mmap-hint-before-thp-alignment-if-allocation-is-possible.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-respect-mmap-hint-before-thp-alignment-if-allocation-is-possible.patch This patch will later appear in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Kalesh Singh Subject: mm: respect mmap hint before THP alignment if allocation is possible Date: Wed, 11 Dec 2024 15:27:54 -0800 Commit 249608ee4713 ("mm: respect mmap hint address when aligning for THP") fallsback to PAGE_SIZE alignment instead of THP alignment for anonymous mapping as long as a hint address is provided by the user -- even if we weren't able to allocate the unmapped area at the hint address in the end. This was done to address the immediate regression in anonymous mappings where the hint address were being ignored in some cases; due to commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries"). It was later pointed out that this issue also existed for file-backed mappings from file systems that use thp_get_unmapped_area() for their .get_unmapped_area() file operation. The same fix was not applied for file-backed mappings since it would mean any mmap requests that provide a hint address would be only PAGE_SIZE-aligned regardless of whether allocation was successful at the hint address or not. Instead, use arch_mmap_hint() to first attempt allocation at the hint address and fallback to THP alignment if there isn't sufficient VA space to satisfy the allocation at the hint address. Link: https://lkml.kernel.org/r/20241211232754.1583023-17-kaleshsingh@google.com Signed-off-by: Kalesh Singh Cc: Andreas Larsson Cc: Bjorn Helgaas Cc: Borislav Petkov (AMD) Cc: Breno Leitao Cc: Chris Zankel Cc: Dave Hansen Cc: David Hildenbrand Cc: David S. Miller Cc: James Bottomley Cc: Jason Andryuk Cc: John Paul Adrian Glaubitz Cc: Max Filippov Cc: Minchan Kim Cc: Rich Felker Cc: Rik van Riel Cc: Russell King Cc: Thomas Bogendoerfer Cc: Thomas Gleixner Cc: Vlastimil Babka Cc: Yang Shi Cc: Yoshinori Sato Signed-off-by: Andrew Morton --- mm/huge_memory.c | 17 ++++++++++------- mm/mmap.c | 1 - 2 files changed, 10 insertions(+), 8 deletions(-) --- a/mm/huge_memory.c~mm-respect-mmap-hint-before-thp-alignment-if-allocation-is-possible +++ a/mm/huge_memory.c @@ -1097,6 +1097,16 @@ static unsigned long __thp_get_unmapped_ loff_t off_align = round_up(off, size); unsigned long len_pad, ret, off_sub; + /* + * If allocation at the address hint succeeds; respect the hint and + * don't try to align to THP boundary; + * + * Or if an the requested extent is invalid return the error immediately. + */ + addr = arch_mmap_hint(filp, addr, len, off, flags); + if (addr) + return addr; + if (!IS_ENABLED(CONFIG_64BIT) || in_compat_syscall()) return 0; @@ -1117,13 +1127,6 @@ static unsigned long __thp_get_unmapped_ if (IS_ERR_VALUE(ret)) return 0; - /* - * Do not try to align to THP boundary if allocation at the address - * hint succeeds. - */ - if (ret == addr) - return addr; - off_sub = (off - ret) & (size - 1); if (test_bit(MMF_TOPDOWN, ¤t->mm->flags) && !off_sub) --- a/mm/mmap.c~mm-respect-mmap-hint-before-thp-alignment-if-allocation-is-possible +++ a/mm/mmap.c @@ -814,7 +814,6 @@ __get_unmapped_area(struct file *file, u if (get_area) { addr = get_area(file, addr, len, pgoff, flags); } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && !file - && !addr /* no hint */ && IS_ALIGNED(len, PMD_SIZE)) { /* Ensures that larger anonymous mappings are THP aligned. */ addr = thp_get_unmapped_area_vmflags(file, addr, len, _ Patches currently in -mm which might be from kaleshsingh@google.com are mm-introduce-generic_mmap_hint.patch mm-x86-introduce-arch_mmap_hint.patch mm-arm-introduce-arch_mmap_hint.patch mm-alpha-introduce-arch_mmap_hint.patch mm-arc-use-generic_mmap_hint.patch mm-csky-introduce-arch_mmap_hint.patch mm-loongarch-introduce-arch_mmap_hint.patch mm-mips-introduce-arch_align_mmap_hint.patch mm-parisc-introduce-arch_align_mmap_hint.patch mm-s390-use-generic_mmap_hint.patch mm-sh-introduce-arch_mmap_hint.patch mm-sparc32-introduce-arch_mmap_hint.patch mm-sparc64-introduce-arch_mmap_hint.patch mm-xtensa-introduce-arch_mmap_hint.patch mm-powerpc-introduce-arch_mmap_hint.patch mm-respect-mmap-hint-before-thp-alignment-if-allocation-is-possible.patch