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 9E7B2C47077 for ; Tue, 16 Jan 2024 20:55:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 302186B0099; Tue, 16 Jan 2024 15:55:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B1B36B009B; Tue, 16 Jan 2024 15:55:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 178886B009C; Tue, 16 Jan 2024 15:55:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 075856B0099 for ; Tue, 16 Jan 2024 15:55:24 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A713B120ADD for ; Tue, 16 Jan 2024 20:55:23 +0000 (UTC) X-FDA: 81686379726.12.0714414 Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by imf25.hostedemail.com (Postfix) with ESMTP id E4D0FA001B for ; Tue, 16 Jan 2024 20:55:21 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YTBtoWv8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.178 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705438522; 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=qQdIf9/3seTYdpMLp0Hh9SVTTL4lH3XX6yFOdn4DVz8=; b=cMs7dgHbKaEtER/k3jI5NRb2YcTFGtwK5FnyZ4iwqjosERnzJHGwI0zWeXHZu2lTZaOW+E sVXMCcCOc1YbCs+2hvy55azi7YgAe9BZiTjBdEu0OSFB1DuRCzmBp+UQFkIb92INy4I+O4 t0JVj8JP+60R07+zqfsdhN1Hp5Ci+Vw= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YTBtoWv8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.178 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705438522; a=rsa-sha256; cv=none; b=cgluNVf1I2uYNhrrAsSjCaxuFm3+fn17PYRyLQHegbHyj6XMaCgYQvT8Ja+VQOoxhr2mMU ak0TlRF4fTY9yS7uw2dtDW5kyenTq/pDCkqz024/Pis6wXwDwFVQCMY6h4OQpBHFWh+nKT q0U+e3BBHd/XtNlcbZ2yxC75nsjpyOg= Received: by mail-pg1-f178.google.com with SMTP id 41be03b00d2f7-5ce2aada130so5408936a12.1 for ; Tue, 16 Jan 2024 12:55:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705438520; x=1706043320; 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=qQdIf9/3seTYdpMLp0Hh9SVTTL4lH3XX6yFOdn4DVz8=; b=YTBtoWv8BszTVOKd3PDZLDTH8ImnE7/3kG+ikhDW08oII3YVmwa98j5hFEo3s3eMRF 4C/yVDYVFCe0yYQihHyRlm9a1J+LBtJEK3b/psw18FQGHDjH7Fr7c7YwQXls2O0Qr7JK m0PZtrsm8LUbUyIOnu7EXHiaQBBCqyoWv+SxFUEZt8KG/Wg5hCJgujH2WQtyTk/r5D+r n1Jn9+4fpElAvFJTZj6GY+STgYAhJTOf7jsj6Pq44T8gR51wnGEHGuMz5RtGwOlIW68C EdUUjkNOhLmFEQr56nIiq35jbhabWRdHH1sUXsCgIbVLMPXZgBFvo8bVDDz7fKt67g6W m8WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705438520; x=1706043320; 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=qQdIf9/3seTYdpMLp0Hh9SVTTL4lH3XX6yFOdn4DVz8=; b=NSGvWsVLd34JpJ48BgMg7lYRvDs796HuVx53YjmS8hr/G0exOgvo5icYaPrQccZBi3 4ynKAooyQu7P9uU1ZY7S7iatiXXACsm30lTWOCcRC8/S+fKgGFxPFgShZdORsstfU+PM 1XgcIOEkrngnNMFf3zNlsfQnn6wP5ItvVX9iy0rqN62xQOcnGpEkK36n5Q32kioeeKnY g3XqwL53SHPymITw6eUvVBE69gre1IY6gfVyMNcKSMejRmxqWe5vlff7E6Eo0fcKu9Xz H4joNy1FY9j+fKPYgYfqIjNQCSHBXWoPUcsCWbnpLBAJsFjPH1Yn2Me0tJTWr2Xh6nFN DIFQ== X-Gm-Message-State: AOJu0YzQMmFUDP684R0MO7znvG7LFMZgwbfW0B41E6+47wwm17dJPNvw X808gjypIE0ySL3NLK0cn+JzmNr1WqY4gx+iHcE= X-Google-Smtp-Source: AGHT+IFc2KL82NxqHyH1mi7Z+u4ztbfA0IHVeHJTHrf9apvxaY907fzHEBuQHG2Ze8BR6Ny0sq3JUTyqmn75o0o6+1A= X-Received: by 2002:a05:6a20:958e:b0:19b:dd2:aade with SMTP id iu14-20020a056a20958e00b0019b0dd2aademr2926763pzb.114.1705438520639; Tue, 16 Jan 2024 12:55:20 -0800 (PST) MIME-Version: 1.0 References: <20220809142457.4751229f@imladris.surriel.com> <3193bf5b-4e22-412f-8c5b-68574942d9bc@kernel.org> In-Reply-To: <3193bf5b-4e22-412f-8c5b-68574942d9bc@kernel.org> From: Yang Shi Date: Tue, 16 Jan 2024 12:55:08 -0800 Message-ID: Subject: Re: [PATCH v2] mm: align larger anonymous mappings on THP boundaries To: Jiri Slaby Cc: 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-Rspamd-Queue-Id: E4D0FA001B X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: d43moxh1o5i5o1gcorbkumm6bf8jrg6s X-HE-Tag: 1705438521-877764 X-HE-Meta: U2FsdGVkX19889MWaObxgxaHs1zR9bGoOTdqQ5AHRm0MLYBH6TKsgtgCfhFc/5D6Lu387ih6Lx9voeqTWhXNQDJEfXGdlA4aLVA5U+3JI+5fJGqJCU7TREHvc786Nqnp4+3xIhnbMlDXyH4UCOx2SdpsoUj0+OJNWux2mujbRPAenvLZsOyvgYdCDvbafrVs+vkh7nJLLoz9VLd6uQ/dIRzMg+2gYweZSjIWXLGgUZ9UWnkpvNeCLfBbdTTiaVJ/un+iOJ12Gej4V67Ct2xUI7/3HZgBzMCkWLgyaEkB4JzrFnmuqs439hilx4Q7KGHDcwiDyIq0EN5FCq93mcrSGt9+Umowo+8v4AITA8p3jIS3PUwvCyf7pOXD9lfmmqImKqO0WG68w08C2aDTU4ULlVEXMe0WwTzGrXzmJrzWi0/hfGEkM2inlemHPnAEb7iRLvW4JYPxa0q5o019k4VXlXRFj33OSVCTfy6c+t/OHtcIIhpTXlOfcvN5DlgUGboCa7svL0WT2jc+x4969tqu/ugZRi2hv5gA0Erm/kkMXqlkMI3bSA7J++cp8JZ8Gp1UBzYy8MkHsQmbUBy/s048ATjBn1z0bCqY/srHcZYGBa02dMKLk3+Ok4Y5jhsUpn24aGzy3elNYCNQdHj9kIU+IjjV19cqQUP7bHzyH1BUvt9zdVgSzpqSvh0lawIml0Jf362jx2UFT5tU3dM5Bw/0eV33rlxDfbHPS/MN7Nc8nJkX000YCuqUxvi2/Jknsf3BM4pAaL/DEmGWaL5gxoYOgz3eDbsk+LMXX8XKWRqQ7peaZcxnb66KQLpeCaL6gULq0TapmUr+KOoQ5mmf9+oUQvRhHPF5ceppMDWLy/gvVbUt7Mz0z3NREPLofPKdofwyFJMfXq000wX/oJsPBMRQS95SuqZ4gkc336RGv7IPGFwJL3+EN/jlIRxzy/9vdNcrX6gb2RoDF7CN0qRAt2Q ytEAgadv O1sIHsLMhw+jWzzHVFb86lDqT3LM4HgiN7MRBr58ty2C/ueVqz8uSY80b0nUFsciTYKy4Med9/2ScJrJ357s2b19CIvnoH3bvDmh1mWUuXrJAPjnykA0BZfYqHVCzt39xB7vIDhVxyEL5CUu3BMFjMnxIcigCNmwATBtpHzuPDzKTRbA7Kx7CnrSMiEtwF93vvWMQWgeXc0+xBrXXQ+UuG52JswOiAD2UEmSk8UUX8HDA8EIun5j0TCvOi9TIxCrk0w/OJjd75YNsxU6+yTpG9NPoJf9pRcjnYIfE4sFP8Dle1Hd8O/FP3+tCc7K2/51m2HszW3yCjOimYOYLqW3AwgpwQXnzi52pVMC12ju0nrvdVumsAwV/2f/YczLnCO/pm3no0mT/6cLjd221ZM53ZFCHXuKi8fGcawM6VDI7l/MWOvcakdqLwdNUS5mx1Peo5EN2dqlYcF2JchM1EqpvEqM2pI934TBROx3a2wJUdtWo855aItnrVptMrZQMUB1BSQfzgOARJZaB4VOaA/VdYZMS+Q== 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, Jan 16, 2024 at 4:09=E2=80=AFAM Jiri Slaby w= rote: > > 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_vmlinux= .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 allocate > > memory) It should be due to the virtual address space size on 32-bit machine. > > > > 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 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... Thanks for the report. I think we can just make thp_get_unmapped_area() no-op on 32 bit. > > regards, > -- > js > suse labs >