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 E2304CE8E7C for ; Thu, 24 Oct 2024 14:14:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 78A1D6B00BE; Thu, 24 Oct 2024 10:14:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7391F6B00C0; Thu, 24 Oct 2024 10:14:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E55C6B00C2; Thu, 24 Oct 2024 10:14:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3D89C6B00BE for ; Thu, 24 Oct 2024 10:14:43 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C99AB16134A for ; Thu, 24 Oct 2024 14:14:21 +0000 (UTC) X-FDA: 82708690386.20.5D847A4 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by imf01.hostedemail.com (Postfix) with ESMTP id 05DC34001F for ; Thu, 24 Oct 2024 14:14:25 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="ChYv/MlN"; spf=pass (imf01.hostedemail.com: domain of ptesarik@suse.com designates 209.85.128.49 as permitted sender) smtp.mailfrom=ptesarik@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729779229; 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=OQFzOo5CVCoEL91pQtXFsiJ0Cpv2r/dDWbECjn6yy18=; b=0Bdsfg0dlHNjBkQan+pFvsXs8Nb8Ga9nLyCtFrTw9yCkEJSz+4+fycJEwYKgkwYW4nBkiD LqA1gZkrTyivVwCE0lE7xdZ4FKtEfGrcKzaqkTZm/coDzik7sjC11rPbCM+0AsGWlT2Y6w szyYj1kAFPHBsqG+sx6uH83cui6ibqo= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="ChYv/MlN"; spf=pass (imf01.hostedemail.com: domain of ptesarik@suse.com designates 209.85.128.49 as permitted sender) smtp.mailfrom=ptesarik@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729779229; a=rsa-sha256; cv=none; b=8dASmiZiPQM8szrm7HMRVsW16IQuZBGBW2uoUy65r6CbJuNKSc9q1WjN/marM+DxgHkQTd kAoYtyEjF4f4Dq99bllXenbSrDyemq2PRB3UhmLrBXENEQzZz3bwho+lmJQojdWU84pOzr XTytIc1ZSw8gh2JaHPUJUIMHFMA4fRo= Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-43159555f29so1082825e9.3 for ; Thu, 24 Oct 2024 07:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1729779279; x=1730384079; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=OQFzOo5CVCoEL91pQtXFsiJ0Cpv2r/dDWbECjn6yy18=; b=ChYv/MlNvUmjEhhD/zHDFxIvXtte7Hb9OMWOxPhFRvUg292i7K/c1l3g1pK6/XNHPR NyuldO4VVWVVyVoGxcQZHuy3x4ZWPLMkPyjgKlR8k0idD7gJP9/s+5tUS98Ng5On+9ZD UuI8Au3Bai0XT0rhzhF2W3IQX6XdKhEIgK6TX9YLn9oN6eTk1mN8eACiKIFb2Jn/ZGO/ CAbNSsYYYXTq7yfkcTIwyLejRFpg5dcR28pEzibJ2pc5q1bH60QyuwLDHfdT7S/yP6pb Wtk9V1JJJeuBOi5rX437SGj+CcjH4VPj4bY1OFFCJCm2IB6wMR97y06QgpPHZdhotGF5 oxwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729779279; x=1730384079; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OQFzOo5CVCoEL91pQtXFsiJ0Cpv2r/dDWbECjn6yy18=; b=MTgDVuGypYM1UZCiuEQLuhH/Sns3NQaxzOkkWc8tgdQ3fDH9MnexOlXmFKPzL0y8PO gpwmR67kQe67RLNOpW0O9H43TLGwCHA8wL7BFHtj2ceOA9/KRpWhhECIX6UYhDAIcbcZ uuJtE1TOD3qL48wjONJhW5O/pIVSfvb7Diwi7kmG0IpaJ03LJW4Y1DPBY1EoALUVBare Iq3LXR4hkdk1dRTrCtpTdlWYHEHytVOKIP/Yf2B00IFpQ5Zsr9dK6qUw44Q3rWfvSzr5 uX78/GwbDcvuwyfYQI9Ny0yIuj7Wl+df7pVOSs0IWLlvjhcJMfFhP2Y3LG7ywphIZVLD cQiQ== X-Forwarded-Encrypted: i=1; AJvYcCVs4G/qtMqf971xo/AHOgvOPWbk10MGhW2qoHKO8XQpWF25jruKEXRji+SqB6ER36ZrYqYqfgH31Q==@kvack.org X-Gm-Message-State: AOJu0Yz5JeHF3hSfVGJZmZuusscOBCjDmKwmkiS9TFofXorK48g5//bf bLY6SPjyInQnRnQsrsJiKKSf/9VzJUVbfXofQqldho/6MsCcngtjtiPKKO8/K2j8gq6Pp95zaak zQyk= X-Google-Smtp-Source: AGHT+IFxtSZQXQIWvRKt7WWnElnMVbb/MwJke6BBx6dlXxrWvHPkhdiGUWHAnC7FM+E6yAuMmQHS5w== X-Received: by 2002:a05:600c:4588:b0:42c:aeee:80b with SMTP id 5b1f17b1804b1-431841c9cd1mr22288515e9.8.1729779279027; Thu, 24 Oct 2024 07:14:39 -0700 (PDT) Received: from mordecai.tesarici.cz (dynamic-2a00-1028-83b8-1e7a-3010-3bd6-8521-caf1.ipv6.o2.cz. [2a00:1028:83b8:1e7a:3010:3bd6:8521:caf1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43186c1ef8dsm46649345e9.47.2024.10.24.07.14.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Oct 2024 07:14:38 -0700 (PDT) Date: Thu, 24 Oct 2024 16:14:36 +0200 From: Petr Tesarik To: Vlastimil Babka Cc: Thorsten Leemhuis , Rik van Riel , Matthias , Andrew Morton , Linux kernel regressions list , LKML , Linux-MM , Yang Shi , Matthew Wilcox Subject: Re: darktable performance regression on AMD systems caused by "mm: align larger anonymous mappings on THP boundaries" Message-ID: <20241024161436.625579e3@mordecai.tesarici.cz> In-Reply-To: <9d7c73f6-1e1a-458b-93c6-3b44959022e0@suse.cz> References: <2050f0d4-57b0-481d-bab8-05e8d48fed0c@leemhuis.info> <20241024124953.5d77c0b3@mordecai.tesarici.cz> <20241024131331.6ee16603@mordecai.tesarici.cz> <9d7c73f6-1e1a-458b-93c6-3b44959022e0@suse.cz> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: 1w7wcsegqs1kbq6ozdtjh1tq3bm5dyqz X-Rspamd-Queue-Id: 05DC34001F X-Rspamd-Server: rspam11 X-HE-Tag: 1729779265-402035 X-HE-Meta: U2FsdGVkX19GBPk98VJtKB86+V3m2QKPuYLC39TqxdMBCfF7I2PoeVi9inicErVHBXi6uoFUPLrEpw2ML129rmB4cxTeU29kzNB8YtbXcy/fNFy2frh87v7XjqnNOycwtrunKGoLKnGNsJvISa2+/Sebtd6MKIWvaeOx9ILXwQaEniJHl2TXOyDUhKXTIVBQph4kZQaTYpBMAsoFk3xKqsLo/z1DiUnK/rjvJx57U5R4Y6xUftOr5cRR9gb069CpwVprA83hEUPGyKQfe3L0jg2ppa2Xol4tViIVqyPbLXD1FACsSXO1sLaHG7GS6QnPxxMlaZDan3/VJcomgF3bMk8ohzIDSNxkYUZFtJqBAqOLMDDKk1Zgj1CUHYpUP6z19NDxt4rjTr+bVzcBSgMeXbD9rIs/uKo+b74oFpNu4k8O4hrKHpL7IJxyMUgbmg6QipoNF6kkjTu2Ql7AOi2sjJer8dzsjInW0N2Nh1MLF0lGy6sQXAmbHeqQSzM5BOtvW4TXMnQYdvOMY4BtdSEEHPMkEArCyFwuj/OUs6dNZAyNfpq3tzUu7s0Aee8O0ShoNeVQET0AJWNzwZqA6+4Q8EZeRb4XrfRGuflBjd+qLh0j12rSY2ruc4q+DFEYgPtVAU5mR36Cm3wUUt93YBnIGzPNH++8lbHasYomCmvZmNpTtujxIsF5iaiSzKmzco8Nqk9B0LDIDlbDxT0Nywla0UVlSP5En26LaWKnbreYryCOFc/pOyN9gRCGNHCsHQ/qU8v3Q6+FGDLKYUraGA3OZztO6zef9bKAOrPoaBm58IJT3eWBwhZGutEjeZomMLPZuXxihhBuYipDGxSwFNVQ93tqnTdtNpaCcxAIMeaJEv/SGHvo6bCIusLctEK5r7iLZHeLUo+gxqMNxRRQ2N5wzzsoQ/zyh8+ZYL3fUZriu32LzFtyASpvi+iKTy9T7dTfOxzt3VwcVWggzea6oJK lSJPpwnQ bn8wASz5WHrHZAAcfi9xKakwURIS9zxK++/qKe2gq+CyoHFYrjj7aI0UScLMPakRtQh4F6fuCJT2kiKZ06B2Ld7u8aDkzpskZCs3hxcirmZmgyZi6Hi9FBTaPPqa1YrsLruFL+p5IwTPV45bM/ouNClCPxgc0VWNRm3MHCYbUaGkXQnkbmzw8WLtW6mf52kKgDikEmtZMl/yKVhrZHOQxPab2/owerByiitsPjvucOnWBXa57golIioNY0OY762n26DDYs1T19eEx2zVz5qysPPcLUjC+WCpa6Glrr3Gw8JmrcUY= 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 Thu, 24 Oct 2024 15:29:35 +0200 Vlastimil Babka wrote: > On 10/24/24 13:13, Petr Tesarik wrote: > > On Thu, 24 Oct 2024 12:56:27 +0200 > > Vlastimil Babka wrote: > > > >> On 10/24/24 12:49, Petr Tesarik wrote: > >> > On Thu, 24 Oct 2024 12:23:48 +0200 > >> > Vlastimil Babka wrote: > >> > > >> >> On 10/24/24 11:58, Vlastimil Babka wrote: > >> >> > On 10/24/24 09:45, Thorsten Leemhuis wrote: > >> >> >> Hi, Thorsten here, the Linux kernel's regression tracker. > >> >> >> > >> >> >> Rik, I noticed a report about a regression in bugzilla.kernel.org that > >> >> >> appears to be caused by the following change of yours: > >> >> >> > >> >> >> efa7df3e3bb5da ("mm: align larger anonymous mappings on THP boundaries") > >> >> >> [v6.7] > >> >> >> > >> >> >> It might be one of those "some things got faster, a few things became > >> >> >> slower" situations. Not sure. Felt odd that the reporter was able to > >> >> >> reproduce it on two AMD systems, but not on a Intel system. Maybe there > >> >> >> is a bug somewhere else that was exposed by this. > >> >> > > >> >> > It seems very similar to what we've seen with spec benchmarks such as cactus > >> >> > and bisected to the same commit: > >> >> > > >> >> > https://bugzilla.suse.com/show_bug.cgi?id=1229012 > >> >> > > >> >> > The exact regression varies per system. Intel regresses too but relatively > >> >> > less. The theory is that there are many large-ish allocations that don't > >> >> > have individual sizes aligned to 2MB and would have been merged, commit > >> >> > efa7df3e3bb5da causes them to become separate areas where each aligns its > >> >> > start at 2MB boundary and there are gaps between. This (gaps and vma > >> >> > fragmentation) itself is not great, but most of the problem seemed to be > >> >> > from the start alignment, which togethter with the access pattern causes > >> >> > more TLB or cache missess due to limited associtativity. > >> >> > > >> >> > So maybe darktable has a similar problem. A simple candidate fix could > >> >> > change commit efa7df3e3bb5da so that the mapping size has to be a multiple > >> >> > of THP size (2MB) in order to become aligned, right now it's enough if it's > >> >> > THP sized or larger. > >> >> > >> >> Maybe this could be enough to fix the issue? (on 6.12-rc4) > >> > > >> > > >> > Yes, this should work. I was unsure if thp_get_unmapped_area_vmflags() > >> > differs in other ways from mm_get_unmapped_area_vmflags(), which might > >> > still be relevant. I mean, does mm_get_unmapped_area_vmflags() also > >> > prefer to allocate THPs if the virtual memory block is large enough? > >> > >> Well any sufficiently large area spanning a PMD aligned/sized block (either > >> a result of a single allocation or merging of several allocations) can > >> become populated by THPs (at least in those aligned blocks), and the > >> preference depends on system-wide THP settings and madvise(MADV_HUGEPAGE) or > >> prctl. > >> > >> But mm_get_unmapped_area_vmflags() will AFAIK not try to align the area to > >> PMD size like the thp_ version would, even if the request is large enough. > > > > Then it sounds like exactly what we want. But I prefer to move the > > check down to __thp_get_unmapped_area() like this: > > I wanted to limit the fix to the place commit efa7df3e3bb5da changes, i.e. > anonymous mappings, because there are other callers of > __thp_get_unmapped_area(), namely the filesystems via > thp_get_unmapped_area() and I wasn't sure if that wouldn't regress them. But > since you suggested I had a brief look now... > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > index 2fb328880b50..8d80f3af5525 100644 > > --- a/mm/huge_memory.c > > +++ b/mm/huge_memory.c > > @@ -1082,6 +1082,9 @@ static unsigned long __thp_get_unmapped_area(struct file *filp, > > if (!IS_ENABLED(CONFIG_64BIT) || in_compat_syscall()) > > return 0; > > > > + if (!IS_ALIGNED(len, size)) > > + return 0; > > I think the filesystem might be asked to create a mapping for e.g. a > [1MB, 4MB] range from a file, thus the offset would be 1MB (with anonymous > pages an off=0 is passed) and the current implementation would try to do the > right thing for that (align the [2MB, 4MB] range to THP) but after your > patch it would see len is 3MB and give up, no? I'm probably showing my ignorance, but I didn't know it is somehow beneficial to align THP boundaries with corresponding file offsets. In that case you're right, and the check should be limited to anonymous mappings. Petr T > > + > > if (off_end <= off_align || (off_end - off_align) < size) > > return 0; > > >