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 95806D711D1 for ; Wed, 20 Nov 2024 18:11:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F0D066B0085; Wed, 20 Nov 2024 13:11:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EBBDB6B009C; Wed, 20 Nov 2024 13:11:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D5C7C6B00A0; Wed, 20 Nov 2024 13:11:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B450A6B0085 for ; Wed, 20 Nov 2024 13:11:46 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 41A6080F94 for ; Wed, 20 Nov 2024 18:11:46 +0000 (UTC) X-FDA: 82807265016.30.E8169A6 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by imf25.hostedemail.com (Postfix) with ESMTP id C3457A0014 for ; Wed, 20 Nov 2024 18:11:06 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=FibWYPQP; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of kaleshsingh@google.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=kaleshsingh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732126237; a=rsa-sha256; cv=none; b=iJEM4g5kz0uM25JC+9OdLu0Ni+o96CUFiRrMLRwpa4w86dEWFjEKrZcjKJQHMUo8ZdTVR7 z65ytdu31SK77e9AyCaGpwD1yT689boNaG2ogu8rpd3HEGo5CGDZ81chFKa1BrdvmTQbWU BXyE87Jr5IzL5n9WI2Sdl2zoL/8YZqk= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=FibWYPQP; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of kaleshsingh@google.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=kaleshsingh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732126237; 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=+ZEhfbz13LmscM92GU4CFvmcXnMTxENjlmy1AcrMZv0=; b=nydF9aLVxTqrOz1ZsKYCkoPvRd7O51QkUKtaUND8K3P5HKYV+3oYLjFrLefyPEq5cA6RH9 iFviDJbHgygER9qJJk2kWjAdfWqcSmaV70VYB2EHMRnRqVOImVLiGRlLXFcZ8fK2usMnLl Cd7zkjkl25hVhS15aDp7agpeP/X7A78= Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-211f1a46f7fso7405ad.0 for ; Wed, 20 Nov 2024 10:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1732126303; x=1732731103; 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=+ZEhfbz13LmscM92GU4CFvmcXnMTxENjlmy1AcrMZv0=; b=FibWYPQP5eY8cHplElHKE6KoL6tI4Q5CEN/UDPpTWE5ABEZTYtF3OipX1BP4S/BQMs R8W909lZ5sLOhYh5TzOED3aVKCT4frDU1PumZpRGaO1PwkZ+1v8ZRuOO0GieMg8ZUPNq qGmzs3sMZnHx1zuhqBM/Mp2wp6kUaX6CwpOJHfQG1HgHjK+LUksv1a2jlY9HuzsfXxon +GfEd4M9UH5jwOl+kepVUQ6a2bkyC4IdlewMDqEj24cUvtWR81ZOLwjCCbmFAmAuoCej ooRxODzEzKeteZwFmFA9JTymwpCgW3Yw/VLUr8w/0VFlkLytqDgDpXeLfqesHSshV2iQ pImg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732126303; x=1732731103; 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=+ZEhfbz13LmscM92GU4CFvmcXnMTxENjlmy1AcrMZv0=; b=I1uhptuqDozXrBE/jO60kKBH9UBBcsG2NfiJN7CAWq/3ImVLkrhynJ0S1KwxY4Sql2 86FfJi/ZkCT7Ol1MT53Y0NCVe9qXYy0fM/JTG9goTykoNEB7x1VngjRBpSqKzvDoz3Cx Cu6wxZn9eDyeruYcbYZ2THEnpGoYi0psB/OJBAw5UoZ0brDZ5ni4liby/pLvKkAd/FaK n7r67p1rHcrSV8VpuK+MlA+r9qDa+ZeEe1pmdKw0Uhqn8w4NnhycZloCQsMDa3DNvpd/ goT/rXbUnK4xR2PciM9e2a3unl2NbvIVncQXq0i2qibumup1LEXRJ8OTspsSH9AP/VoQ 6w4A== X-Forwarded-Encrypted: i=1; AJvYcCWzyETdqnudrk6gId/X1taoi7krcZAKmeC7MbyGSFcT1C4IZLuDeTmJXDyf6TGoUg9+BLcE9fbKfQ==@kvack.org X-Gm-Message-State: AOJu0Yx6IZ66O9lUBiMP1P0glj2a++xVRaRJvLetwJ1Bouvzq1hTNyX8 zNyFH4TIH6SWyzrFcpaW2eZG/ZqwrtzlnyEih0tW/tFe+ueMJ1YXA3xA+kGq0qZEAKFNF1gSSDC pKia50b1zuE5EJwSsccwC4iBFHT7MLn7deXlZ X-Gm-Gg: ASbGncu9bMZ4mWRcGbejklDAqF4kkIeF7r1QlsxAqgIPybNh7Te+upij0l7M2+893ye dcLr/bIOuR8oRPyyXmxJyBg10zp81a7JW9CVQnvQSZ2UXAQxp0LUt2/FW+zYPIalU8A== X-Google-Smtp-Source: AGHT+IHdYabz3C+xJtFwEDGe82K06BCCU9X9KG7kGpGxQnakHaUJ1yK6rjgOVQR4DkLL2l3XL/XAWN28j9hdnZXlfmg= X-Received: by 2002:a17:902:dac3:b0:1fc:60f2:a089 with SMTP id d9443c01a7336-2126e159d11mr2604655ad.17.1732126302690; Wed, 20 Nov 2024 10:11:42 -0800 (PST) MIME-Version: 1.0 References: <20241118214650.3667577-1-kaleshsingh@google.com> In-Reply-To: From: Kalesh Singh Date: Wed, 20 Nov 2024 10:11:31 -0800 Message-ID: Subject: Re: [PATCH v2] mm: Respect mmap hint address when aligning for THP To: David Hildenbrand 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 , Yang Shi , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: C3457A0014 X-Rspamd-Server: rspam11 X-Stat-Signature: pwcfotoepc1nmabbxq94u173ri8kcd3b X-HE-Tag: 1732126266-864578 X-HE-Meta: U2FsdGVkX18ECWLyxxn8JFm1Zek4P3VpudNAZqjS2HQxtuFXPy6yJvDKjSJWkHLS11hXZoCqlot9m7d0K7IVk0HPpJSvkoVhsQwED9oag014Gnw8T6WXNW3rPARif39MgQF/if3ubmprZ23EOPo2TMaoQiEoUlY1hZ0kXuOMAc4J6h8l8sPdNMG+iO5gsmjpdWpeZtz3Jr7pulYK+SsIESbnuK9znBQ0TPHzWI8nJWll52tQYKQ9aX+Yq4uertC4iNHeTJSQ3ksIitaZUk+5ftwMo6fHJQ3uXdAV6d+es90t4vcsEI/i4AajUnFiAMUpywA+vhmqVV2mOrXMDRDPH4lMjVxU7eOjQcxXj2bZWUT8NcCK4PfLyREO+ijb+dCfeXj7DP7YGer/Z7hK8qh6wDfz1/h5bAaZCrq7t0gLAcvSfk+aWzn0yKsYRg7vVYgZBVcnvQmo6ND79zkrxHv98kj4NiE5YU92yPxayM0MP5KwGzz7oq+KQp2tzJhMwn6zzebXh/H21Xl3qDWMwSXcUj8qcSDDpwBeQCBOIVGwLkJX1L4+MN99J+/8Tk9tOy1nSbOj68MNb9B8YHHbKfcVlOqfRm4hCj68Tll2CHXx3htLmgUHWBgodZGqUcvBAtFcK45fFMqjliNjiet9t5PKa5vhBgphSZXtnx0r6MDtkTmtdE2L0DpgIOIhcOH4w84ycW/WntKGoD9tKu2rms4JOq/JOaRJDGagNrj4dVMG7p6HpQYRywRm0GM0aiH3i6UYC4gFSuyOFP2oHSdTen0roFZ/Ny++BTpqO+EQ+IRwotlNkgz3JIo/PhvZHHV+3OVj8ptc78a5wHfodHo4A4dXMev0BS6o0RYHul8f4VrWJjYNLYeWHoUJE4YVWWj4o2bVIqr2ap7RTbucuVYnoMekU9ZA0MGhea1tLbvq58z503lgik/++ckCYIofV77UWKXUik178DRpfzHTTRbIKnr 7wsVD7If oBi3AsaAeVyJ4sWK/hioVQK8rqRNQJrxujkOTLfSSf4UkyC6/b4k+OPi3q/50eKSdiZlxWm5CWrhx1rWddRQrDbke3cTXj7VPZVUDbetSyZHY1wQCIo3WR76eoTOimCui+qGOJk+B+srFyRly3hTsg4WWyt4y6cIdFZByDnCY6tajxCqnN+zrAk72yOlP/Xt09xQ2x4mHKSZc+qFksicGlwzV/YEXDH9V/SxhIzkGnbJ7QtWghUYWKdvHLne2mMwrY6/69ddzafkaxOeos9cB72MdUbaZVTCAPdaAbqGyT5Hk0jaHQar4N0hpweeWJe6aCIbbQGxTUubpBOhBlfhVbS3NrT3DA2pEm0SW57GaXHfkNWjtPRb/3D5pkmQo3Ak6LHVz9nFC658C7QkXEIJftrHqswom82rcGLYGxnvUGRGH11c5g9gjIql7AV/IhyR4OoI4FD0AP6kzISlZ6PmM1o1ECbxCF30AhRmddJc6rVSqvLprl7ODarTKyek4Hcrvled+ 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 Tue, Nov 19, 2024 at 6:35=E2=80=AFAM David Hildenbrand wrote: > > On 18.11.24 22:46, 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 in= to > > 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 = hint > > 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, for anonymous mappings. > > > > Note: As, Yang Shi, pointed out: the issue still remains for filesystem= s > > which are using thp_get_unmapped_area() for their get_unmapped_area() o= p. > > It is unclear what worklaods will regress for if we ignore THP alignmen= t > > when the hint address is provided for such file backed mappings -- so t= his > > fix will be handled separately. > > > > 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 > > Reviewed-by: Rik van Riel > > Reviewed-by: Vlastimil Babka > > --- > > LGTM. Hopefully that's the end of this story :) > > Reviewed-by: David Hildenbrand Thanks David. Andrew, when you have a chance, could you take this for mm fixes please. Thanks, Kalesh > > -- > Cheers, > > David / dhildenb >