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 6C7E1D68BDA for ; Fri, 15 Nov 2024 22:44:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2DFE9C0019; Fri, 15 Nov 2024 17:44:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EB6A69C0018; Fri, 15 Nov 2024 17:44:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D091C9C0019; Fri, 15 Nov 2024 17:44:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B04E69C0018 for ; Fri, 15 Nov 2024 17:44:43 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D4773AC665 for ; Fri, 15 Nov 2024 22:44:42 +0000 (UTC) X-FDA: 82789809354.05.4EDF056 Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf22.hostedemail.com (Postfix) with ESMTP id C2DD8C0014 for ; Fri, 15 Nov 2024 22:43:43 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=0ekXCimj; spf=pass (imf22.hostedemail.com: domain of kaleshsingh@google.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=kaleshsingh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731710591; 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=ZZwlo1UiJxfRk6Ay0RNijnjJNxXonIfP1NSZKq36oVo=; b=eQEYrWv9D8FfGd2sbJbnVe02C0yvATzh/NwM6AHNEZzJ9ES/tPtvIL4sf6wsAun9RSNKgC Ne2/Xfl1oBzrSlQsCruY5kEFd855dEpZsE8GZiVFqazKNtvCij9BXKDtHK5xBiE0FVSsxN 85tSgsGca1AsG5b1WKR5s/61Yx4qVGY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731710591; a=rsa-sha256; cv=none; b=UK1puTRPsR0ZI1Yp/h9mCgk79vJ+Hmzpdzi7iXB8rJN0x8ezZmP+k+qG5KAXddWHcoEtSE GoCkmihzCQE9tL1i67bhXTCK5p+3ekhE7OvDmGwYHTbTml9xVVB8/zO/AF66/ihPeFhSOp ZQ4yPJefRrzM6QYp0Ivwa1GmpWtgswQ= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=0ekXCimj; spf=pass (imf22.hostedemail.com: domain of kaleshsingh@google.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=kaleshsingh@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-5c934b2c991so3050a12.0 for ; Fri, 15 Nov 2024 14:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1731710679; x=1732315479; 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=ZZwlo1UiJxfRk6Ay0RNijnjJNxXonIfP1NSZKq36oVo=; b=0ekXCimjw/id7QxKhFoR4mYtzfmTP6mmRFrbfKVhk6kqUWCSNL2Lrem4PIMC0XNpNa L0s8XmkRLJlHIX0OLZt47Ds2lyS7vnlqHsJE9OBMBbZbOEvbfMRMqXLPlveoAVpy9Gx3 UI+u6QJlmr7T7VyhkBaKVNWrOtiN9jA9mNRkFA6mlgk5zPvQe8WlK9nGJD1691bxaQEW yCE523OcGuabyG5pW/u3orDpc73WB2daOI+4Sf2c5bezf+jQSKD22t+AMUg9rs9y/pMo lKdmZD6LqEFr8KAom9YKcc39HdxVRXhR90NQ3rk5/h+hLBDd8MPP5sJgbYW5GhSmvOLu v3kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731710679; x=1732315479; 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=ZZwlo1UiJxfRk6Ay0RNijnjJNxXonIfP1NSZKq36oVo=; b=YGBXSMicNN5cufeS4oVEfi5+KcLT7Rxcxc4JTuohVHrX7omul6bAJz9Pyw+4H4xF6u B1qG92T32TBnJtiH/buYKveib60iDQoDZ6L8LUqXeZ/BEclyHT6XScnlN6jpXr2BWDo2 k112RIoYq/2xu0/3Rx6aXYf8FezzU/5ObnxoPv82DEqHLJnER+g3jdICTQuaxc2+kEDP dKPiwIdMTazE/LLddJ21PPJcCM1q41zR6vZ/daCT82LszB5IzO5bMlda6nAS+fc7IU31 gNhMfSQgAjWw10LC85YJBT8IU35mZkp9FDGjfGUzUvwv5PT5DtAd3v2j4/dsZrIZQrY8 l+1A== X-Forwarded-Encrypted: i=1; AJvYcCVhj67p3HhFEBQgl+8OyeCMMjtscb1waufNH5nFlwgFb/5cRU4W+KMc+8SV+Qt5NIx7AJZfOuyS5Q==@kvack.org X-Gm-Message-State: AOJu0Yw3eEgGp9IC9++jvDZKz7lTQaGqpiy07jBAz8iKfx5JT69gK9Aa pIjRjZYbmcwRjmg0qws8YOCeGpbykZ0IbKsl/VQp6Fa23hfPhfn8nxszuXSZ+eoimz6zA7E8T1K JK+W1hfG5Zibd5P65w4N6psqeYqZOGbPG7YdP X-Gm-Gg: ASbGncucEu78EhtrX7Jp7no2wqjbbolZt7vFuc7RmAb/+21NFTvz6GWmEwLWGr/IN6t s/3nX4K0vw5qADzPawJdanXr8bnIIt6zHA+XsEfhVzS90GEE8/sz7Cjh6lilFKw== X-Google-Smtp-Source: AGHT+IHsjFblmGfPUCdxMHEnPyRjyNMUKVr2ov3wlP/7H5jpPAvTNsfV494AHMMACrwmQdw4IXpz14TyC92EHp/0GMo= X-Received: by 2002:a05:6402:1a25:b0:5cf:7b8f:3ec0 with SMTP id 4fb4d7f45d1cf-5cfa28a8ef0mr20067a12.0.1731710679310; Fri, 15 Nov 2024 14:44:39 -0800 (PST) MIME-Version: 1.0 References: <20241115215256.578125-1-kaleshsingh@google.com> In-Reply-To: From: Kalesh Singh Date: Fri, 15 Nov 2024 14:44:28 -0800 Message-ID: Subject: Re: [PATCH] mm: Respect mmap hint address when aligning for THP To: Yang Shi 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: rspam10 X-Stat-Signature: jqd6t444yd917z8sp3ckjt8e6fm7p1k9 X-Rspamd-Queue-Id: C2DD8C0014 X-Rspam-User: X-HE-Tag: 1731710623-717594 X-HE-Meta: U2FsdGVkX1//fbpwPbeiftlTjinEptuPZMO5qaez3rDPhW21rsE0GDiJapAd7scyxahgyE/HslL7kC8w0ZmITb5ZiCw2gvYHbtCZisZXJ5WFaY21UZFyq0SV41ileSH6ZAS9UBvZ5FxXJcHU2FrL5Isu1ztAmLLGKk0Us99ym4d6jZYNymGKESIxq9mhf7CyKFy+9Qa1eJ2WrOuZjTH+ayOUHa9SonP9S+jNax/hMhqTkWCFY09Vbz/5l0b+KZhh+56kWQpP80EgVI+F1YA7TkneUUpi7b6ZoIdnnGakFGmmKujrQuf7AlXp/EZq0yX097yNwkm4zeu++leHIe5TDXF0seGzdFSBytLMoV6GEbFX+5EjjiEUU7onIbnZmgCnuFOFBuTeLVrhKzq91voLXnV8U7J/DnQoxCr1Tlx1Z51/XwpKeTJ5rJgUPP9xZ9dP5ultNL3zYCp6voUV6I1rZRpT2W6vJ+k2+OgwQSlx7DFcIWtCvSfxb1LxTqlUlqRpTglNACHgcl0t0rmj+jTEcwmdRI3bX/nla6XzF3RRvsxMEJsVAZt5v0fEckAJTtgNq50Px448K1gJY0YLBv+AIw+ZD5M7DzaZsMTXTDRaUi7FjytQZm6KQd21flQ22GFTrlj/y/u3fSiUG1HzDse9mq72y9GxVGVYVUxZh5M8/FeSUWs/sXevP4rZkrO3Y6IkxUsyBKH78hDYUXSgo+cjL6J3apFkWFo3DKldurqDexmlgeQd61qyuMBP4VwVfcU4AaJedxOGpskDQSurRHe1WSqhJkMxIG7ctTteHSENKnsOuYv2fIWNYg7umsgJtAkBHb1ZqWA2mdg1OzJA5nGUURhPNhlu6Z8SizPWSc0Ii3miBhsIi3HDgc86s03iV55JH7MdWUSUSoow2ZhioYuSG8FueRJMlHPHv2iBUgOiMpVXz6TrtiIjtjLqOMGHaeNkn+JfgKTtlcNSYKcKA5w RTGcMVZx IAeQuynj1U7arCmlcKTqfmJZgcJ5WxbAn4vMsCg6NIbGsnFPQVJFE2eHdvcpqY2lHwU7ZKLJ7p5d7WEUVNumpE7EnEybWJKKWKdLVu/aLFDWjdd4y/3jGZFJ+UNKFmUONrC4sFRwdoqU4ka0qDZSGHyk5vkgWqw3wWtYplcg3/qjTcBZkSERltVcI1xolStrx7B7mS2mqVlufspr0VKn8T5JUC6dvyENJi0h1KPKbpD+ge5raO2bFJt+HuLRxFCJbZF/Ln34EP224rHoJXa2n5EL9DP7Dy9+ND7qM5d4HW55NA5JTC4ne8Ppn5BTA894KPYdkFZVQGaE/u61xGc2wukjoEcBzKkTY3zii1HqtadVnXq2lUl4FrYN2SGTCFpFQsxR3Br5TZftRDl/oEkIdjw1HGA2SZ5SUBzBPGNLETJlHzqMNXcpj+lJz6Lg+01R08GD4BGJ6i3rWSK3GRo6ExkcIUDOqHGgaWjvjdl5VEbIY/Y+3MRV8PpfAehchHaFBm0nU 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 2:15=E2=80=AFPM Yang Shi wrot= e: > > 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 spatia= l > > locality of related mappings due to the forced PMD-alignment. > > > > Another unintended side effect has emerged: When a user specifies an mm= ap > > hint address, the THP alignment logic modifies the behavior, potentiall= y > > ignoring the hint even if a sufficiently large gap exists at the reques= ted > > 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 differ= ently: > > > > - Before THP alignment: The requested region (size 0x200000) fits int= o > > 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 h= int > > 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 th= e > > hint only if an additional PMD-sized gap exists beyond the requested si= ze". > > > > This has performance implications for allocators that allocate their he= ap > > 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_vmfla= gs() > > 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. Thanks Yang, you are right, to cover the file systems that are using this for their .get_unmapped_area(). I'll move this to where the 64 bit checks are done when posting v2. Thanks, Kalesh > > > 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 bounda= ries") > > 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 lon= g 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 align= ed. */ > > addr =3D thp_get_unmapped_area_vmflags(file, addr, len, > > > > base-commit: 2d5404caa8c7bb5c4e0435f94b28834ae5456623 > > -- > > 2.47.0.338.g60cca15819-goog > >