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 5B3BBC47258 for ; Thu, 18 Jan 2024 00:07:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B1C716B007E; Wed, 17 Jan 2024 19:07:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ACC666B0082; Wed, 17 Jan 2024 19:07:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 994CB6B0088; Wed, 17 Jan 2024 19:07:19 -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 8819F6B007E for ; Wed, 17 Jan 2024 19:07:19 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 570681A050D for ; Thu, 18 Jan 2024 00:07:19 +0000 (UTC) X-FDA: 81690492198.14.6B8AE31 Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) by imf01.hostedemail.com (Postfix) with ESMTP id 9075340011 for ; Thu, 18 Jan 2024 00:07:17 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TSoJfBMT; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.171 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=1705536437; 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=yy8czIk2rbohhNTQxzmNyAw9METMhxbRPhYbJMUzgcs=; b=Uomjvi4b7tvuHBShLM6WfFCEV2qLX1gpF617tkc21wASgrFsFpijerDS4hlxWHvR7Zlli+ nvAW88MIDwhOYeFRiVZuEomT0+NjFuBNi00kAQKCE0xATp0yJkCLMt38nECd09Lj/EPlL/ 8eE5Q2WrtP9AMazNpClACxztnOqGZb0= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TSoJfBMT; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.171 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705536437; a=rsa-sha256; cv=none; b=Bgsn4cVSZbRzwy+6PD9CQFbBdUGNN2z4gbss79hlt5JgCWJDKo+NoNdFBMYbmXKXiBgO+j m8HT2b9k8EUFqgF0PtmuZvjwFsdU04i93OVNKy8Ov/jy8A6eu9qFPMSOs5oYj7OIRLTo9t VJFlzRd0npOxpNjSugOasX6OOMvcUKw= Received: by mail-pg1-f171.google.com with SMTP id 41be03b00d2f7-5cddfe0cb64so5399072a12.0 for ; Wed, 17 Jan 2024 16:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705536436; x=1706141236; 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=yy8czIk2rbohhNTQxzmNyAw9METMhxbRPhYbJMUzgcs=; b=TSoJfBMT+D/f8+07ydHEskgK6OgkDwmmqHQKQNE0I3CuC2yKHt+qtg38p4zbKMl0EC Vj3eKC7jo/91fWs4q2B0feBPZ7TOfc5ZLJKhVGbPdGgqs6Hn2mfXvfUeZRYEjJUidaeQ Dv60C8tl8fDQ4uhWPaj49XdIpJkwCArsTvyqiwx0W7pqRICJcqyaoi97pbLgeYClmgkZ EESE8ba9L2DEZUQBrdfj21KiLrgd1TbglRdkA7h4E2Yg5avLx+ByDMrkjGs4KlXZOwyc xgsTW8I+hjaaLuP1YdNwDBMynquP01jARshq3ToCq53tMa2k7Jg6wAv/rITudHFF7byZ oq7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705536436; x=1706141236; 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=yy8czIk2rbohhNTQxzmNyAw9METMhxbRPhYbJMUzgcs=; b=km6hIv9pZ5Rvgkd+W2gduEOXLIqZxWPrW4YVeSA4OfEe1483a8mnbmqoYKVaQecBXV b2L+t+dYcLYvGrMVQ8Kcfb9L0SCIK3Zx3JdYcI+qpoEKXWnMYspAZNWwhEW7HXq2vXuN yKx0zlfs/nmK12Q0QbzpLcVLOVzTrltefPH+2bSBP7rr28ffXaTOAnhaoLZ09CbLBfSj Xq2g71Qt5eQCDq+/7jnQtyTvWOy9lc6BBQr+QpIQxAOtKL2auewU5cYqhKYI187t9CzB pzrF8LYJoL7DzmZpi1nzGeeA93S0guY5ADlkAb+374VmnKzwkhPijfdlejOf7eS7VN4Y oesw== X-Gm-Message-State: AOJu0Ywau0BkpAqVYvpF6RDAmijUA3/7a0pzyk3vo7oliLXakxEfZ1j3 VWFIwuYUxXfw1mkX46puqBhSqbOoS+DGwTmNmdJ6DAxLT6k+na28UbeaFA91K2T9S+sCvavsBvr Mpa4GpA5jRDplMgH8mCS5M3FPJU4= X-Google-Smtp-Source: AGHT+IGTZ3/9oOp+KJxua5AWIKkzAEY2l07bP3Xtgz2flb3B+FV2NhazsCG2blxZb0yeSxDv3ekJIDwj5bL8uLcaZEw= X-Received: by 2002:a05:6a20:9c8f:b0:199:bcca:f090 with SMTP id mj15-20020a056a209c8f00b00199bccaf090mr41480pzb.47.1705536436426; Wed, 17 Jan 2024 16:07:16 -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: Wed, 17 Jan 2024 16:07:04 -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-Rspam-User: X-Stat-Signature: fjx8ck1mog8741snqoona64o4u8tbu4n X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9075340011 X-HE-Tag: 1705536437-295640 X-HE-Meta: U2FsdGVkX19uTYZtyqrqB/GIlqpMABr1YqnpgmkgJdQxpaUDFYX6Rj4VRXUsuziRgegMvaCAbgtwDzaYEgIm5uiJIpbb3LYkAkd65kEQ1TMg8dJamufLf5n5M29tRYycldTP6Oc5O7A97uMXB7Hv1WniQI5wM5d3+4smgCevDSYuhxtqrkKSveNmU6D046uBlKOEKZ2jSlfvXRXRblx7BPq5Hy4rwT5hO28kSV8pob/sGTKNtvZ6IKHaYImDukkOGPFPD59nLQVRHyivj0x6LDuvevARxLZd5aWLByosFduCYpfXquKrWUpz3o9GsBdoIL1pcXtmsUi3yWXrgmSw+FwoGY3LGmExge90I3Ze/E3ZeqYk4YlI9YN2+AQpDM/O2yqeJkTg5xiutF5uOGZYaZ/zZETiNewlRKcFUjX2/dmLFVTM1GsBS2e0ZNPVI8y7WTxaaYgX3SdL63F/gGf06HHbn/6qJZHeo85Groi/o5boD6T46BE8DpDbFIV7++dIxlMMijy91WZgIrRfpFA1AQCI4nFmmqA1JHzvgJFLuhRFiB16E7fUqsCocYpyMmE7UY+MeWGRHLP8axi3gqxSQbOO8QOqNmdunwfI18JnwW7rFyDH0/2e9hDOV34oURoKFxLmWF6oiOCWY9dGsjqGtfci/Ba/2j9z8ekhEqMW3Wli34sqNhn2iTSv1YJU3r8Zp4CCYxbKh2TG8OBAGfr3aEhJ+a677DLWlaHtdNUxRpjlMYB3595W0YqHqlB4ZlJH76rwFguS+VxCWz3lCBvQGC8FaNdDSsg8czoRD7C5ERUKgyRFy+f2ormAAEPFS5vSpJ/7bdRlOK1wBtBX1LHoFJ4kyo+eFTWO5vdCb+UAyysGl43cg5SAMj+ZP2lnNAHlgRuZpDJpbboRcVvvy19XQEMcWeSyx7PRKf8GMw0gsQ0AXF/aktS3r0xeREcMZQfW7JRk/AyQF7Js22q2lqV ArnphMu+ 4thymsBe6Lstxs3SxJwSRJi+tIU70wfdR/PmETmG1fZGOg1KhUyrhyCQYzGq3ncvKwUJowp12LCnKs1GNBARv07rtX/6O8tnupCOtscKY9DzfTl7nHeiFLPrWThKz2+hEnDKdQbkvi65hv8iQgt0OWhY5PzrvhnJFeLcSINnaQGgZhfkBRNDZp2ueVhsgX7P5s8XW8SKB6chYiA7jSLA+lzqKhALBYgQli43PFHa3DzepoR3HzkAKH4Et8WRd8mTJXgabSg4IJD4ix+UTZFl4iVRAWJDJI3l2v7nEvqcs0fUHT707GleEDiL45sU9RXmNM+aM4fMy1CYl965LQwLuYMfGxYdeQEFXbh6xLhkaSnWQaFigLd51FKRl90j5ddouDvKuLl/rgz2o4fKKSiu0qBZVv5FWrDJvkeGDL91GkdJjDGe8gqsoCyocxpbyNqm2aqWQW6IYv+6ztOqhuHqN1t4QMyNgY8KCArVnW3WasXG+pxRqH+14Arvlzrdejc49G2eYmOV6UN0Y+2+7OK3d3aQX1w== 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) > > > > 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... Could you please help test the below patch? It is compiled, but I don't have 32 bit userspace or machine to test it. 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 >