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 3768EC47DAF for ; Thu, 18 Jan 2024 00:11:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B6EDA6B0095; Wed, 17 Jan 2024 19:11:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B1EA96B0096; Wed, 17 Jan 2024 19:11:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E71E6B0098; Wed, 17 Jan 2024 19:11:14 -0500 (EST) 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 8C3AC6B0095 for ; Wed, 17 Jan 2024 19:11:14 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6673B1206E0 for ; Thu, 18 Jan 2024 00:11:14 +0000 (UTC) X-FDA: 81690502068.05.8FF91D0 Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com [209.85.128.178]) by imf25.hostedemail.com (Postfix) with ESMTP id C0BD6A0010 for ; Thu, 18 Jan 2024 00:11:12 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=pQxaS9Jp; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.128.178 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705536672; 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=LoDZgidcfDcF1qVsgYjkpOu/KB4eCKUf/VJq/PI9JJY=; b=M5aq5EBpmGow/PqpmJatgWZe2Gt8hKFJb3+FAFqF7FRLArc5cvCILoKfo+bq/rdczDIMin dF+MTk47gNWqUrMN7uyRLkhF8F/WewII8rVg+eBYjZFZPn0p3R7TY4muovvBg/QKIPeTSO IC4Ojz+tJYp7Vw2z7Oqo9Zw9+N5R5Yc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705536672; a=rsa-sha256; cv=none; b=k5v9q1ujHqMNaxRb64zDKq6EEtoPfSXPD+j7xP7X9YsJKWSEUamqyru8vFlapc+JE7XPOm X2AhV4lpt1rxcRbGIMNwv2tG/e+PxsDDl2bTJQDHT8oFdpVsLXhGdgL5nCYRc2ymUvw/Wt 7vcTAD5Q1eu+bpmi95mzLbgHznNQ7W8= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=pQxaS9Jp; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.128.178 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-5ff828b93f0so3823517b3.3 for ; Wed, 17 Jan 2024 16:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705536672; x=1706141472; 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=LoDZgidcfDcF1qVsgYjkpOu/KB4eCKUf/VJq/PI9JJY=; b=pQxaS9JpiYInV9eBPKbiKRSX/w+7ciYEVYUZL84fBJ+KLEqalIvlNssOKuOnEbKhB8 JhLy+dRBb0WQ0/s0IKnbOk/FnEV/r5PqeJL8TAlJC05I4OH7roypZ5GnCOqTK11RS1wB kDMKvZp3rJqFPqiDaWzhIT9mokiqv3VYp8rM0PA00J/xhXATzYmu82SPjGTClvHSVdqK 5NkwLVbROoMhjmhun+17LWIxYlzHNj8WICL0fe0/9jeWg39+28a5T5ncbjelLgYFgex+ 6+tLeZb2KyRy2PI8TYa/mc8IM7wk1pG6gdOpobGeyvn3h3pcWLgJ13EIl/eOCUH2je59 tSOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705536672; x=1706141472; 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=LoDZgidcfDcF1qVsgYjkpOu/KB4eCKUf/VJq/PI9JJY=; b=Z+78iyYi7upfFwdbZs5VHda2VjIXKraJsN34o6Qfee/PS534Uh2dbo3O9Vra022UB8 lLqxfdzepJ8e0J1m/CcbpwxRFfQyc8m7Rvb0C2DkT3mvxzKEswgAL8pFR9e9xuM5hCm5 2DOpaEIPBUv7DMNvwed1YUYh+2s1nm5qfk6ugWyygQiuYkc/IzutVNCBsh052wuf9GhC npgT8P63mK4cZ/CIPFgdfTaRIgzlTRe3vaoXJxJGovoeGD0LOFqxf3cMjogW2gwqGrbE UhjxzKA9ubuRIs/0Dj0HaWCgEJ/f3prJ7YgbuUS2BZeEML51fqYNgsph92Q9ovFl0fRT 9aag== X-Gm-Message-State: AOJu0YxoinlcxO1u2afuz61K4rLaNO3JlfS1EtwUji/T240imar58U/V 9pLdGkr9uKJWxIVQzrNT0JFnnYhks2yIaTOe5iobyWmzHRCgPHJpm6RMyCNPZtmfOS/NmeFyz6g rw3KGXsHMjR9UkeZFSlfDHAsR0bhKb1bYzb0v X-Google-Smtp-Source: AGHT+IHLrYpLoBhkEmiQ/l5XTtyxJhQzMl5guq0AWfDPU3CEMKgzuCK8+TXekH1cTOV6v7QI7bHSur5R1aZ7Tfy7yUc= X-Received: by 2002:a81:a08a:0:b0:5ff:5222:5214 with SMTP id x132-20020a81a08a000000b005ff52225214mr40555ywg.22.1705536671713; Wed, 17 Jan 2024 16:11:11 -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:11:00 -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-Rspamd-Queue-Id: C0BD6A0010 X-Rspam-User: X-Stat-Signature: emdxgrg9nsxsndq3u5qb44wysbinyd4k X-Rspamd-Server: rspam03 X-HE-Tag: 1705536672-541930 X-HE-Meta: U2FsdGVkX1/natDZuqop+2ASSM59lGGye+k4qJs7U/UAxapXt2fxjlJWSONObxwjEr78AbGPQs3LTThAmtJho2SumuVhtUBXRjAirEpRoOYRK39GIsVaeKIKkeKf4uQW70T/643IDtZzMfH4jXyNW5JsEWaymkYgx7DyguuH5+6WWn5Y4rpzRSKB4rlbECujUft5howbB2dZPbZpgYiHi7+e8Ay5qLyj/trED/BZaWKvf3rSLYuiFh9QO5jQwn3QtoREtbV5ZZPAjN/jGzInYWTFHGOnQNTU8dgu6LshXqTTCn3/a6kI67CqD9JiDflsYEReQapil2apLQ8po+hp6A4O3sUv0JSOo7prlkKamULynX8tvnC94Zzk5mkB/kSAh+unpDjhYzTbQ9qpu1O5aLo6sTInhsFQ4NaKA7af8wHCE6YjqB3SB43KY6dkl3TC2N6hcpa30O5tFuVHwSkBsexNpJjd+ugtf1kQ7PJE0KImeWqnBSrTVVtMZh3DFTX3C6+2SqipEGmHKWj+yLIn/0im7EKfO607z75UmSJ4VQE+1s78xOtbxMrO5kXrOAo4LpMfg0/4pgMW3r9EbzKzQxju8OyQWJw09BK9no0oF8iCMB+gKMk0ik4HRznrKjh8OzKu+FOx0SJU1lxaJAXQjuWzGdODVdbnhOyqfBtf4i8YCfL3QGWDGLCTiBrNpUgqfKkeCYeJjugsy7WVC2benJSH9g4ruyRrUeNxAIYRiZfHgTnGSwNfYNNxDNQvmBTxfbokqR5AIH9DNppw+ieRahH2hRF9CwDHlEbJlNScumt6q/i0GFuHBMtnsR582VdUiUryBsn63chwxKnAB1OBn1SVs6N2BJwacHFuk2LZhpKW/sE1+bilsvGa4jGYXxEkmgoR7GPN0sgY6o54oFiHO3kC1kbLRmeP5RsteUfXrFnuwqkl9/NJ6BsaPSs2403wIiBn0uE4RcTdgrEgudB eWQ== 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:09=E2=80=AFPM Suren Baghdasaryan wrote: > > On Wed, Jan 17, 2024 at 4:07=E2=80=AFPM Yang Shi wr= ote: > > > > 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_vml= inux.btf > > > > > > > > crashes or errors out with some random errors: > > > > [182671] STRUCT idr's field 'idr_next' offset=3D128 bit_size=3D0 ty= pe=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 alloc= ate > > > > 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 fi= x): > > > > > > --- a/mm/mmap.c > > > +++ b/mm/mmap.c > > > @@ -1829,7 +1829,7 @@ get_unmapped_area(struct file *file, unsigned l= ong > > > 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 s= ystem. I mean it's x86_64 Android emulator, so kernel is 64bit. > > > > > 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 > > > > >