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 63795D68BDB for ; Fri, 15 Nov 2024 22:15:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C89F26B00B3; Fri, 15 Nov 2024 17:15:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C39596B00B4; Fri, 15 Nov 2024 17:15:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ADA7B6B00CA; Fri, 15 Nov 2024 17:15:35 -0500 (EST) 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 877A96B00B3 for ; Fri, 15 Nov 2024 17:15:35 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E188EA056C for ; Fri, 15 Nov 2024 22:15:34 +0000 (UTC) X-FDA: 82789736526.02.DB02649 Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) by imf20.hostedemail.com (Postfix) with ESMTP id D1E691C0005 for ; Fri, 15 Nov 2024 22:14:35 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JlJHRcLW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of shy828301@gmail.com designates 209.85.218.51 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731708753; 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=zM323IeHX5Wao0Wvn3Qxm0EBhrnoes7GmduEknVbsqI=; b=Ed1VstpjFS15uQIiXpxuu8YtgV9XMl4VhDLy0eHjIeU2JMeZ/RUD2tWIc2Q1/vmq2bb4Rw P7rOwHOqZTbR+u4rirAo5hAMTsAgmtF33L8gKxRZtVkoYl5irbionTfnBvJXj1xJSQKbJQ 3EH6Lu9SZzgSZ8+5+hjf0za4toCRSPs= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JlJHRcLW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of shy828301@gmail.com designates 209.85.218.51 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731708753; a=rsa-sha256; cv=none; b=1xobkDcU2jHS+AlWuZnbnD8bFcaJqQvCmNryAqk7EDkwaZ2b5JQ6tXPoGWW5ALB/ysWodM FZPEw4FjgIOmD7b8/IF94ZDUWCPs/crdICN6DDKv1ZpHvlWd8rTZm54/K8Fh8PdkpIo/zp 51i6BlQ9ZX+LNnrBdBzH/PCS0dhnqN8= Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-a9ed49ec0f1so387793766b.1 for ; Fri, 15 Nov 2024 14:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731708931; x=1732313731; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=zM323IeHX5Wao0Wvn3Qxm0EBhrnoes7GmduEknVbsqI=; b=JlJHRcLWm4PFUZMgl3CDob/e0uDCAYBCwlFNg0+sxVs7ExHorbZt21U6c9eJy3DFiP 2CdipBHLub/dRS1+leOHSejI1WfqarbjUnW75XLYH+WVAVp7mRnbfNHVsyf3eEtr7vm6 y0VeZ9oLVCYaiLdf7XsV+2/p2bipdGZxH6qhfyhhqcqn1R0neulwBYAeKLxPLqSHN2ex Iba40ZOnjEqRCqS8UfPwCWWn406xKkN1RSjQRkJ3BJrRu2QPNrjQur0RkBzSEqAYI5oa xf/S8CD5ugFyg06CiRBngaZgBsAh3NFXkyHNsVgM10Sr0U6Whr4KjC1HHrpKxpuezhwD kyeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731708931; x=1732313731; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zM323IeHX5Wao0Wvn3Qxm0EBhrnoes7GmduEknVbsqI=; b=I0C4UWIpNo8ARm9803oKR8jaonXVp67+02xFQpdkqj82pf7DVULIvF7WxUvKOz6z4a p39eMMKF++2VyB3NK2YLu0sOvoHRsZdG3WyNzL8ddvUvlU419nhB8MhczHE+nZ5qYtvY aXjKQlPq4eVhVk6RiZ1ZDF+dlVgGC7G5+jYz0yNf74rUJeyZL5lEA7HRodPagaYyIgH3 nYRkhly1qtj3tNtdmGi1eFlvAw+/LvGjDazfHIwIOP/BkP+RFU05C+AYaxk792gv2EOh RAAiy++lWfiSi6RAQp+JA2kObMU3ELGYL3jh9THUSP6NTcuBCCaW6bbidQvCBnQNkryS c3RA== X-Forwarded-Encrypted: i=1; AJvYcCXqU21MM+xxPTae0h8iNVsM9Dl5E88b1NeKalATVQZZhd1sXoOx1EVp8Nn7lscOA3EYkUSPFkwNyA==@kvack.org X-Gm-Message-State: AOJu0YyOIeOA/zCyivJ4luYRzXy9VRfZ4UsudWfffIW23OKknq0CWbvj JSF9gedLHWuQ3iNwDMOd1sApuel0JuW75cqyapwRrnBUJ3uOJKKZ/J6d8hTPxXpqyAKnfFbw8Sp UYdF8V6EoYtSMzuW5c7ZKuLE4Ee4= X-Google-Smtp-Source: AGHT+IFpg42qBOE2i3RJF23Qu7bb0Wdl9LRB8XOn80l6Xa/542IJqFJwKaXgpinZsQaFtyqmA+qDNSpL9W8JJoFJzJw= X-Received: by 2002:a17:907:6e94:b0:a9e:c696:8f78 with SMTP id a640c23a62f3a-aa48354da39mr338250966b.51.1731708931183; Fri, 15 Nov 2024 14:15:31 -0800 (PST) MIME-Version: 1.0 References: <20241115215256.578125-1-kaleshsingh@google.com> In-Reply-To: <20241115215256.578125-1-kaleshsingh@google.com> From: Yang Shi Date: Fri, 15 Nov 2024 14:15:20 -0800 Message-ID: Subject: Re: [PATCH] mm: Respect mmap hint address when aligning for THP To: Kalesh Singh Cc: kernel-team@android.com, android-mm@google.com, Andrew Morton , Vlastimil Babka , Yang Shi , Rik van Riel , Ryan Roberts , Suren Baghdasaryan , Minchan Kim , Hans Boehm , Lokesh Gidra , stable@vger.kernel.org, "Liam R. Howlett" , Lorenzo Stoakes , Jann Horn , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D1E691C0005 X-Stat-Signature: efodh9ekjrf1g4ruzk7x7minudipr6ot X-Rspam-User: X-HE-Tag: 1731708875-407742 X-HE-Meta: U2FsdGVkX197i4ktSS+eDROJjUMJ0atDgCI+uW9Ei82RKyDA2S+OSP7tVtwMMaVT2/4kadoPdnZrklw8UX/QX+wqJPe7RY/ewx6XUgPmxwhPl75/ZWa+LyIo3zi1LymOLI9pWpO5hsxH4QMvjTGU1u1OkKLuu3WZadY7AH5X3qnCkJkkW9nnCWPUZDbdiWQKp1kifzgiLkQ0L7J3uP00A9wtbonj5sdGECdPi3hPkZQEa19i81XKnn4Nbkl9bc4oqnC1Pxch16xrfdzmrJuwSgquDRNzznRN01pW/O8RmfEg/7H5O4BGFoDG+FWVS0bbEDnIvu2s1QPxTs4YdWR+aToNTXKLsjb2gzXxXZ4CmU4LYHNIw3w3bjR5o2ftJrOywtVGTuNY93e3AEJqkgIyyGQkj5mIuUH3vlrNbdZX67aq3LOXO7C2gU8fbkJurTN1gz+XsLEzV80SodzG3uITxIX88fxE1Ujt0c7k00GViqdirSmlaHeh7793onmJce6e1ggzbu2ODh795owJvjF/4GsvRSLXmQW0CGlbSITRpmfXwuGTEhLYiV8kBTnId/JNA3b1BIJxBf6Fju0uKhQ5vG1zwR+ZktzQSUCl4QfDhI1zN1CIJJIZpp5fuiMH1gsl+1AplrIrYv/ct+AXyQ/rQDjNgzaSKm4cCIazm7hmfhbMlApTFK30QtnCBu1zoHw8Y6j9TZ8xm6WNmC7QYUKq8skBNhp8RuNIxpikfsJ9OBAy/YOuMaQzAHUdY/wRc6slSFHHhRghnYK6VQlP0/sX5vBEg/3nkHWTsDGFcAtkMrVQttaIO3h5e4mHBMNK6qv95E6V4w/PPNhNYPgpHl9yShyuJfqXgXvug4/S0AoWbbfzkrwDaKS45s/VLeldK9oDTsjLqmsntbFhH8T+vo2dH90oSYd8olOvEQkoolD1HJ9ax0WQuzBEH2TkbhR2jkL7Bx3HMSenbaf45EbFCUS pe3X6G58 xNvuHBzlBAGVNA2wF0Pyo1oLAT0Pgj+AMDDIHAJcvoHNuuoy/Lzn9a75xotyJxWhtuyccokgecRxV7C2ocnTBWUskNt+MMfo1DvJ3JOwCgjZLAZD8BXOvNU31KvLtznJFrczDS9PmWIAI6QPd5vuOSqwHB2o3K0re8uSLs3ggSX1/+/E6c/ThzGUVjHxE9haxbgRuW8XMKd7mneRDISDQizwOFi/shzQh2Dnh3DV9ectGU+NN5Iy9dx7XhZwkQJdT5kCFZxme4jJ57icl8k/ur5ipLwvJCo7+bUnyiq9yIuyZ9Wxg+YKOdK49FyEP5gajdSy6exh+84iuO9fa+YVMwGa7jMOAOBgj6xhAV5LnZQFI71HYvQQMYFVEsM8tGF/94/ELex/cMbcXm2IwlZZ2oTuC5V1J1kIwnEEL23rY2tiZaIqI5JwK/dTCRi7hcAB98OZvi3MFWeZbGLlkeUMFf6PTgwfmf3nqcrm0OH0lt15GnTHZS7IKbSNfVGLkuKxbzqU9PmftMybqxwThjIfZR7osnr4dcIbDSmNCf0z1pCMePfqOk9tioN5Dy+mGpP+mfo+uf/MZ8zdCjUjwIgUb4VszmUnTR0Ab8DAd 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 Fri, Nov 15, 2024 at 1:52=E2=80=AFPM Kalesh Singh wrote: > > Commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP > boundaries") updated __get_unmapped_area() to align the start address > for the VMA to a PMD boundary if CONFIG_TRANSPARENT_HUGEPAGE=3Dy. > > It does this by effectively looking up a region that is of size, > request_size + PMD_SIZE, and aligning up the start to a PMD boundary. > > Commit 4ef9ad19e176 ("mm: huge_memory: don't force huge page alignment > on 32 bit") opted out of this for 32bit due to regressions in mmap base > randomization. > > Commit d4148aeab412 ("mm, mmap: limit THP alignment of anonymous > mappings to PMD-aligned sizes") restricted this to only mmap sizes that > are multiples of the PMD_SIZE due to reported regressions in some > performance benchmarks -- which seemed mostly due to the reduced spatial > locality of related mappings due to the forced PMD-alignment. > > Another unintended side effect has emerged: When a user specifies an mmap > hint address, the THP alignment logic modifies the behavior, potentially > ignoring the hint even if a sufficiently large gap exists at the requeste= d > hint location. > > Example Scenario: > > Consider the following simplified virtual address (VA) space: > > ... > > 0x200000-0x400000 --- VMA A > 0x400000-0x600000 --- Hole > 0x600000-0x800000 --- VMA B > > ... > > A call to mmap() with hint=3D0x400000 and len=3D0x200000 behaves differen= tly: > > - Before THP alignment: The requested region (size 0x200000) fits into > the gap at 0x400000, so the hint is respected. > > - After alignment: The logic searches for a region of size > 0x400000 (len + PMD_SIZE) starting at 0x400000. > This search fails due to the mapping at 0x600000 (VMA B), and the hin= t > is ignored, falling back to arch_get_unmapped_area[_topdown](). > > In general the hint is effectively ignored, if there is any > existing mapping in the below range: > > [mmap_hint + mmap_size, mmap_hint + mmap_size + PMD_SIZE) > > This changes the semantics of mmap hint; from ""Respect the hint if a > sufficiently large gap exists at the requested location" to "Respect the > hint only if an additional PMD-sized gap exists beyond the requested size= ". > > This has performance implications for allocators that allocate their heap > using mmap but try to keep it "as contiguous as possible" by using the > end of the exisiting heap as the address hint. With the new behavior > it's more likely to get a much less contiguous heap, adding extra > fragmentation and performance overhead. > > To restore the expected behavior; don't use thp_get_unmapped_area_vmflags= () > when the user provided a hint address. Thanks for fixing it. I agree we should respect the hint address. But this patch actually just fixed anonymous mapping and the file mappings which don't support thp_get_unmapped_area(). So I think you should move the hint check to __thp_get_unmapped_area(). And Vlastimil's fix d4148aeab412 ("mm, mmap: limit THP alignment of anonymous mappings to PMD-aligned sizes") should be moved to there too IMHO. > Cc: Andrew Morton > Cc: Vlastimil Babka > Cc: Yang Shi > Cc: Rik van Riel > Cc: Ryan Roberts > Cc: Suren Baghdasaryan > Cc: Minchan Kim > Cc: Hans Boehm > Cc: Lokesh Gidra > Cc: > Fixes: efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundari= es") > Signed-off-by: Kalesh Singh > --- > mm/mmap.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/mmap.c b/mm/mmap.c > index 79d541f1502b..2f01f1a8e304 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -901,6 +901,7 @@ __get_unmapped_area(struct file *file, unsigned long = addr, unsigned long len, > if (get_area) { > addr =3D get_area(file, addr, len, pgoff, flags); > } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) > + && !addr /* no hint */ > && IS_ALIGNED(len, PMD_SIZE)) { > /* Ensures that larger anonymous mappings are THP aligned= . */ > addr =3D thp_get_unmapped_area_vmflags(file, addr, len, > > base-commit: 2d5404caa8c7bb5c4e0435f94b28834ae5456623 > -- > 2.47.0.338.g60cca15819-goog >