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 1D7FCC47258 for ; Thu, 18 Jan 2024 00:15:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A3B586B0098; Wed, 17 Jan 2024 19:15:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9EAB16B0099; Wed, 17 Jan 2024 19:15:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B30F6B009A; Wed, 17 Jan 2024 19:15:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7F05B6B0098 for ; Wed, 17 Jan 2024 19:15:49 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4CD881608F8 for ; Thu, 18 Jan 2024 00:15:49 +0000 (UTC) X-FDA: 81690513618.18.7700984 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by imf30.hostedemail.com (Postfix) with ESMTP id 8E76B80009 for ; Thu, 18 Jan 2024 00:15:47 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=e6gw2q3K; spf=pass (imf30.hostedemail.com: domain of shy828301@gmail.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705536947; 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=IynhXCUI0Z6fOdMc/TR5aKK0TAPM3oTT4ipOlj/ruhI=; b=y6BKJGF1E7BJ4XCrqNuqN4NroOuCK+hFH4PqFNHVUWQPO2V3QnxscxdH37GIzPyWUxEEtW 82SUTzgI6QVY2SNYBvvOtFjZ/eSz0Z33T4umO2c3GsCnKBMMYsPgrhQAcw5I/CF9EDqIyK sLGowTEOr0qhuY0/niOaW189bMyOBi8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705536947; a=rsa-sha256; cv=none; b=NRFQoqx6qb/K6NOpzKTaWnW6WfF3MYVtSdH7ndoGBIuIgDLTkekbCciZAusjSTutM5z4uz 8QwKMvzf1em6NdTSwxP95BTXRM87efR+CN7ICyIwBkBPtyJ9e3jh/g/5zyz/MdbBfMAAqW TVSqw/WCCDGs3BoYxdM9hpJg1aR2aLo= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=e6gw2q3K; spf=pass (imf30.hostedemail.com: domain of shy828301@gmail.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-28d0052beb0so7173920a91.0 for ; Wed, 17 Jan 2024 16:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705536946; x=1706141746; 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=IynhXCUI0Z6fOdMc/TR5aKK0TAPM3oTT4ipOlj/ruhI=; b=e6gw2q3K/0WXa7i9sthczrmjdS1ihCRc2OwTWMrPvnmiGpBa/SlftgcRwabwIMMss9 YBmyoX2HZUJtQGxccu9dHnGabw4OB8tPEAqYl2z7S01u9WyrPKgmCRU04IKXvsuL+tWr jTijNmtCpZkZ91ZjRV4PvYsIFVrwFX7Hdj0j+aDBny1D9upOthpXLVUJwZj9yNniuuu9 dUid2GtHo5htf8DWTPih6+lIk4VvhzeRlu0IlfK6Ei7M3Ltg49yGKkohvwFAlSBBnmma a4JAmcugii0G++vBCGtOGazll7l3ysfcalVoayOyImvEnW5/6V8pKGLw8ZuqrIyqGRVc /nHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705536946; x=1706141746; 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=IynhXCUI0Z6fOdMc/TR5aKK0TAPM3oTT4ipOlj/ruhI=; b=vX6sPdMsV551wFkrzt7xUrYqAir+QTtvAbibu/1fGj7IlK4MsUIUYKv/z1+TIrhYx5 Xy4pfRw5H6nbI7ySr5mzbe6DmXKkeuYU17p/84/xrBSsyEzNUy952MKSTBGBYI8TtOdL JlIFhHmu4IhWHMdLD4Ndv9Jc/0MigqQxrPRpT+ij2hNYIwrhOpkALvqoiHXYNA5LStX7 9eXfszRe5toOGNK6RHGC3X/urI1/mWi0gV03o9qRN6rFzEj2SUtPHN03XLVbe1UWN99g DREPIRmDoNfK+6I97yzgUjZhRm1MT+wxw4wrQdC0Z/CLaebbzFDJ5GjAlrD7RuaeUM7+ yV7w== X-Gm-Message-State: AOJu0YyyEQNiINLxo9LDH+5VhhWMvNzrdjo0bAVyp5xvFTkQBxqUXKxn HtEr3AK+tHWpSWV7uENZhRc9+m0wAEKgEmmEr9mfTK7kniqkUUVjT35ICWB9OsWz1hy8N6JtpHo C+XpFEj1BAQWqs0Wl3YlAO4cdKKo= X-Google-Smtp-Source: AGHT+IGqjtmkSakkUWRfxiSFpKIGHiORUfAPzuYNIYFG8LDABnOjD5KjNhbQcS9B0dX8m6m11jRPvBQmBzoIZ5Ld8hw= X-Received: by 2002:a17:90a:5d8d:b0:290:14a1:d6be with SMTP id t13-20020a17090a5d8d00b0029014a1d6bemr44039pji.75.1705536946436; Wed, 17 Jan 2024 16:15:46 -0800 (PST) MIME-Version: 1.0 References: <20220809142457.4751229f@imladris.surriel.com> <3193bf5b-4e22-412f-8c5b-68574942d9bc@kernel.org> In-Reply-To: From: Yang Shi Date: Wed, 17 Jan 2024 16:15:34 -0800 Message-ID: Subject: Re: [PATCH v2] mm: align larger anonymous mappings on THP boundaries To: Suren Baghdasaryan Cc: Jiri Slaby , Rik van Riel , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, Matthew Wilcox , Christoph Lameter Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: aqfao1xaip3owknzcmyxjwtwmgub4dtm X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 8E76B80009 X-Rspam-User: X-HE-Tag: 1705536947-280616 X-HE-Meta: U2FsdGVkX18sVKq5nTBa2bSJK5vVfFHQJtHfZUFGbrAluzpQ3HtD6rINb8nMUeNv8B2e7P6nxjgau5/5T46BavtJSvEO4m8gwm4LQ3c1ra5oh6TMRAQxoF4fuuEeI7iI/mUk7zy6GkrLLrVw00oi4S+Qer0R6iZeBM/k9tL1upWyG9QiA/2SiZjAmLE6EvoHpRZCcp5xftB6MVOebscj2ku1tSP4Fp0xVRZ2CjiZoBKEVwZKbTh9wm1l4g36g3+0HKwllFIYcpHEpAKq00ZiXlKWJaSyZXwirvwnWDVtaxP5HZnlXRYSdZu82s2aX+A4HWby/uz09XCQaBAK0bJmonXgWUEpH9ibnAOWC7e3LYnCwuiAlkEdbGJPQRCeKqExSKkmBTkkhq6PjpMP3SZZ9iAOw+NcxNEKxdhFhcjRZtTRFdowxrCsc5YyBzep60qDc0FlCDyrJ+f3J9OuFePNBBdb+IcUl4vYHwgztCvZAOTiUkU598y7RmASvmTHBNI86cHfU5oPvipYWvCQ3Cx07PxcHbR+NiAmcPE3HTjXwGDYDSOe6uWl1Sf6uQxYjQRMmcD/I4QklSB5tOwb+Tj9uvPWrIEGn/yu+V2DefRNl/7prDCQrux2SsXWVObeIcmsUVYA5tg6rWtAy2tH7+t6dQsguAQ5+40StWJE3Vk9j/FYmldhRPeibixeizF0m3fwRqJeqR5yKQaq1OTjyV68YbMza5Pn1ScAmn7S5Ll2mWAlCCEk+xnNSW26inxWZSpbpYAy5BbzdPZpW1uO/kAWW2rv9MHAPjCthwd9PDY0DGHiCti5KoL6LI9AeB7cImfnbvA4gkShLWhkZrNrqRlNu2EwodGpPJx2Q0yINLcw+obalTj5koJVhnOsM+QvGQhFktIN4feIo6WDAr9UES4knF9vgUC+E8ZJyqHytTUhogw/8at2rZ02tNoV7Fj9fDJEthZ4GuExdHuwkYZFkXn ZPVPF1IL Yc6CoV0IblHxoBTf2DZ/qrBKE/XpEvharUYs4KimaOKMmU5uR8qrjQkIrq8iXc52hDkMbW5ZvVHk4fG7U6H0pI8l0wldYnGZNbnUWyut3KKXbidFxZNr+qktx0FfXXc1u48DKAxV5tGUlHGYgtH++h+AfIL7ARnWwMh+F+Fpm6MJPaP5dZWtxeNgHVrnOtXWIg7/DvtwxsLfiGIr1e/LFOjebkRqc4CBJLVRdVJOmuWsV0GX22WyqMPVEh+s0V3xBvJaEVgAAhfTmkXZgFsbnEJoE3QAuQgf5aQL7dRI5VHbGpR6vnPSEDDMZladfq2YOOd4w4pjCoV5Lh4BPCAkipk+qTTkmrRjqwuVcbcPt0Gis2hAw3ciuFkM8iOs4kTFhEjOA8gGPj1srDp3zKxkAuyRWONW6JpSBW6+4YqodrfalBTmPBkdwLGHuJKTzO70nY1fc4TeERbYzffOnxuM1DAmH/ic/vxHKCwu4wIrm9yzCZ4okPgRbEP/c95Zb+p4WmclHsu75z5fCLx6AXwbu7DI3K61+kL7YNwzbJht9UTGOwNYEU8UV1Liyo6bPZ1nn4sbK 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 Wed, Jan 17, 2024 at 4:11=E2=80=AFPM Suren Baghdasaryan wrote: > > On Wed, Jan 17, 2024 at 4:09=E2=80=AFPM Suren Baghdasaryan wrote: > > > > On Wed, Jan 17, 2024 at 4:07=E2=80=AFPM Yang Shi = wrote: > > > > > > On Tue, Jan 16, 2024 at 4:09=E2=80=AFAM Jiri Slaby wrote: > > > > > > > > On 16. 01. 24, 12:53, Jiri Slaby wrote: > > > > > Hi, > > > > > > > > > > On 09. 08. 22, 20:24, Rik van Riel wrote: > > > > >> Align larger anonymous memory mappings on THP boundaries by > > > > >> going through thp_get_unmapped_area if THPs are enabled for > > > > >> the current process. > > > > >> > > > > >> With this patch, larger anonymous mappings are now THP aligned. > > > > >> When a malloc library allocates a 2MB or larger arena, that > > > > >> arena can now be mapped with THPs right from the start, which > > > > >> can result in better TLB hit rates and execution time. > > > > > > > > > > This appears to break 32bit processes on x86_64 (at least). In > > > > > particular, 32bit kernel or firefox builds in our build system. > > > > > > > > > > Reverting this on top of 6.7 makes it work again. > > > > > > > > > > Downstream report: > > > > > https://bugzilla.suse.com/show_bug.cgi?id=3D1218841 > > > > > > > > > > So running: > > > > > pahole -J --btf_gen_floats -j --lang_exclude=3Drust > > > > > --skip_encoding_btf_inconsistent_proto --btf_gen_optimized .tmp_v= mlinux.btf > > > > > > > > > > crashes or errors out with some random errors: > > > > > [182671] STRUCT idr's field 'idr_next' offset=3D128 bit_size=3D0 = type=3D181346 > > > > > Error emitting field > > > > > > > > > > strace shows mmap() fails with ENOMEM right before the errors: > > > > > 1223 mmap2(NULL, 5783552, PROT_READ|PROT_WRITE, > > > > > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 > > > > > ... > > > > > 1223 <... mmap2 resumed>) =3D -1 ENOMEM (Cannot all= ocate > > > > > memory) > > > > > > > > > > Note the .tmp_vmlinux.btf above can be arbitrary, but likely larg= e > > > > > enough. For reference, one is available at: > > > > > https://decibel.fi.muni.cz/~xslaby/n/btf > > > > > > > > > > Any ideas? > > > > > > > > This works around the problem, of course (but is a band-aid, not a = fix): > > > > > > > > --- a/mm/mmap.c > > > > +++ b/mm/mmap.c > > > > @@ -1829,7 +1829,7 @@ get_unmapped_area(struct file *file, unsigned= long > > > > addr, unsigned long len, > > > > */ > > > > pgoff =3D 0; > > > > get_area =3D shmem_get_unmapped_area; > > > > - } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) { > > > > + } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && > > > > !in_32bit_syscall()) { > > > > /* Ensures that larger anonymous mappings are THP > > > > aligned. */ > > > > get_area =3D thp_get_unmapped_area; > > > > } > > > > > > > > > > > > thp_get_unmapped_area() does not take care of the legacy stuff... > > > > > > Could you please help test the below patch? It is compiled, but I > > > don't have 32 bit userspace or machine to test it. > > > > Hmm. I think you misunderstood me. This is happening on x86_64 emulated= system. > > I mean it's x86_64 Android emulator, so kernel is 64bit. No, I didn't. This patch is aimed to solve the -ENOMEM problem reported by Jiri Slaby. I believe his test was run on 32 bit machine or 32 bit userspace on 64 bit kernel. > > > > > > > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > > index 94ef5c02b459..a4d0839e5f31 100644 > > > --- a/mm/huge_memory.c > > > +++ b/mm/huge_memory.c > > > @@ -811,6 +811,9 @@ static unsigned long > > > __thp_get_unmapped_area(struct file *filp, > > > loff_t off_align =3D round_up(off, size); > > > unsigned long len_pad, ret; > > > > > > + if (IS_ENABLED(CONFIG_32BIT) || in_compat_syscall()) > > > + return 0; > > > + > > > if (off_end <=3D off_align || (off_end - off_align) < size) > > > return 0; > > > > > > > > > > > > > > regards, > > > > -- > > > > js > > > > suse labs > > > > > > >