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 3FB29C47258 for ; Thu, 18 Jan 2024 00:10:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 971B66B0088; Wed, 17 Jan 2024 19:10:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 922D66B0092; Wed, 17 Jan 2024 19:10:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E9A16B0095; Wed, 17 Jan 2024 19:10:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 6B4D16B0088 for ; Wed, 17 Jan 2024 19:10:00 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3E78B1206E0 for ; Thu, 18 Jan 2024 00:10:00 +0000 (UTC) X-FDA: 81690498960.12.CB87CE3 Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) by imf07.hostedemail.com (Postfix) with ESMTP id 81B4C40007 for ; Thu, 18 Jan 2024 00:09:58 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=wAcHYok1; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.128.169 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705536598; 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=nWj/m/g6g6US/nsTw5NmJ8dd+nkVoLNoyL8nmayW6s4=; b=iFocl8ynBfKqKt7PhzInIAWFRiVJT/lhGG9mtOEYnfGYhwnIwEwaDWR2CZYPBPaKoeJ7fd ciEWSupvX5FZBP8AiHimtfcolQpAg5zWNs3UUCPRJe+Z88+jlDXAB5CAE2AS+9+1vhsAni +6gjGS3idX8PJFLqwrFmMZNbusQWQF8= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=wAcHYok1; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.128.169 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705536598; a=rsa-sha256; cv=none; b=lqDJukyxBGLjc1Mwjy1lV0VjA0L5SlHRYmo00XT1izaSZYXlCgkdWz5aXIlAV1QBJ5ULiC yPQf940WrTieXC4xHUCfecnncSqUvI1LefdVGG03j3D8XdeDfPEOm/owU/FrtfdSV+ij2S QAnfzFfjY02KdSXf7zNXiBRM4O3qD9A= Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-5f75aee31d2so105635027b3.2 for ; Wed, 17 Jan 2024 16:09:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705536597; x=1706141397; 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=nWj/m/g6g6US/nsTw5NmJ8dd+nkVoLNoyL8nmayW6s4=; b=wAcHYok1utNCLan+g8rA8mYL8wj+2oXA50mGrHuipn4UKRHqTCAE8CKiq5WWqAuF6A b+TkDvrFBrrTKyHAWEsV5XIgZgQUkM+OxtjaYUCF7RaWLTwjp1up49vrtzq8Mr3g78Ma /Iip1VE3pUdu4b+Umk307GY+WGZmuwGiOUics6hYHjkUncNdl32qgh+cqLU/lb+VnLUD AXXdEklBPN8c25B9+iDjCCt4vXb+L8nH+HZPj5ufWLvg899LlJgx6p16on0OPTPT443M snr0tqXeQ9IAagr4iMiH6nH7vAeDTV1pLpaLQdPlnFXUiKmV1fENF7UnDidgu5bqaG+U 4UDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705536597; x=1706141397; 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=nWj/m/g6g6US/nsTw5NmJ8dd+nkVoLNoyL8nmayW6s4=; b=JRVujCVAzSCnZOKwhjdbcIGJ+K/yW0vj3qoX71zKzbPr/s+toX52M6kTy+jZU4S3Gi 2bJ614a5uRODkii4msK1wRz+ZY+4DreU+Va/lDp2xDlhNDmYuo+fVMVSHL47Kb5ggRpT HPxj42nOFRJLSxlSNpfM2l/77rqQ/EmD/krnyfCneOq5tJU8e1VKRQzTM+dOl36YNcvE h9bXyMozUXO+O8nBj115zhjPlxBusXbdgovcMYOYMzCg4oiZkOUsG2HpdmyyClZr5OkQ yN9jMqExq7dZmoMYAv0AqhIqkQkjFJBuVc+h57u7H+i+H+bag6URl/qbF1F4dg5ZXCG1 UwjA== X-Gm-Message-State: AOJu0Yz5ez6hzhfuwnSZ2gowxdThMvCF2hC5YoIpYkBmqk1Obvb0P4jj /42YStuoPYPCKhN8kj8sQ+WOy6jFji04LJT5Zu66K4kMPFdab0EqQ/jGs5chkgvnBqYPcSeYpUu Q/Fu5KZqhrGNpBbcysB3LP5gha5z6cnd2p5l+ X-Google-Smtp-Source: AGHT+IGkkyQpgYqThfZopVmNDT533MxU48Z7x0jPEpVKuX8XeupBR0DuLlFQJLlLZfmwDdSnGUzYv/dErsJU/cMwbR8= X-Received: by 2002:a81:7103:0:b0:5ee:82ad:5151 with SMTP id m3-20020a817103000000b005ee82ad5151mr32472ywc.74.1705536597460; Wed, 17 Jan 2024 16:09:57 -0800 (PST) MIME-Version: 1.0 References: <20220809142457.4751229f@imladris.surriel.com> <3193bf5b-4e22-412f-8c5b-68574942d9bc@kernel.org> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 17 Jan 2024 16:09:46 -0800 Message-ID: Subject: Re: [PATCH v2] mm: align larger anonymous mappings on THP boundaries To: Yang Shi 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-Rspam-User: X-Stat-Signature: th1smhqbdsjzakxgo17syeub9r8t938s X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 81B4C40007 X-HE-Tag: 1705536598-14512 X-HE-Meta: U2FsdGVkX18npj8YrUdKUUR/ZWvp59O33LgqHWfrvB3Gw3tQWFrBLUs3QwLJwdpiUhtmbpZm1SxtKzv9f7sSd1Qi+9DvusDjmQ+0hegki60kP/HJDiUlqWLivcnA6pWI1Lg9WXGpsAyWdBP9sw7DMz7E9gzj3N9UZr883w5XdjS9yaiEtQ1674vdeTY2+3whTRZAvu9eIZV0abZKtzFSD2uZX7TqpD64uooNFBK5AHFQ4qaFx/qtCianym4m/enaAvjeg6aWrscs3ZZCImcdQIgJVcUyFxtCV1ePn7SVhupDYGpVhQbfGoSvHaAzjqB0k9lYyMZR7lLWhyealyvEpz7fxBSdo9myMdsiz6ImuQozq77D85Le2/nlyby31i84lKDvIqGYlm97BGePcSJSACIaZsrrM7/fOQhoVfAXh6AL1HgpLwkCYC5d1PsfuoHAvhAVeiKshHvNrQRaBSYTaVVAAzhZbyV5h/hpWJBauJ6FmHtiEuOEuBROh+CKQPMsSyYa3kCO4d21tGn/rVK8KsmzXQJT56DKzzfZ/r7kclA3w5GkLU6L9WlW7PBxkqV0BB2AIK9QMxC5ohMesRSiniZYH5a2qMKKnNJIlusf5VMXu+hLajN8c0MF2q9zAY5hXVcZlqkHvM9taL6MCJxcI/kbdf9PTZTuwUrHFrKjHSnZDjvs4yYwS8WkgCcA+WFCaCtA+DtbEGPL9lQ2vUih7CvSmh7KFi9E+keI5NcPgmcZjC5Xo6CaHDu0v1z7Qx4B+XFT5tp6q2CT4UfsgYSioTbpWanKnpNuY+t1Z27JW4gXJu7JwXMDgrpRCcHTA/5MNaqODKEnrLhj2O2b7G0RXPA5rgJURDQgdA3qxjDEX2Io0yRzsrjXRSLbdiJByp2VkU1LZticpvwhS7qNUd7TuyxxRdBoUpA8qlZ69XsZKfrYTtWQAxcJEhXCd+y6CN4yOg8IUfAwyzABx9bq2l/ DPoQup3U Dcws0fBINcxOmxdWGqD2qAcX1dr7VsrOvS4iUuLAuWqKKcQWKqliTtTUax7Lj43JzqutFseHIezHKxxqVtPTeIX0wLAf6+z52FaIJ7Ex5/wMzBFzV9viJ/J/3PhXrUWJT/ye7Po44kiEj34usrf+dEd1MNHI+ZTcpv0UfCsrBJlko3j15klAOYIxiU26C/VfMoMZWWyILkovCQfWqjDo5NzqiQg2Y8injcnhk8uqq1k8CVy8+oZT/ExfzySrdAL9vHQLUENdi+/HoYXscka3+rGkwyFy9ZkLH77Ozfit5VBSWyUZ1RfNvus+n3bhJC46/dc5NhAzCSBgIiXLbqttEGlwFJoK2EHApXx/+0DIR+v10g3OPJ/rVOOIsKQ4KMiPNDUAzY1XuRKRikUDTu9uw2mr1/tbT7TtnrJZgbx/91XiAcsM= 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:07=E2=80=AFPM Yang Shi wrot= e: > > 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_vmlin= ux.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 allocat= e > > > memory) > > > > > > Note the .tmp_vmlinux.btf above can be arbitrary, but likely large > > > 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 lon= g > > 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 sys= tem. > > 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 > > >