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 44921C47258 for ; Thu, 18 Jan 2024 00:28:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA7396B0096; Wed, 17 Jan 2024 19:28:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B56F96B0099; Wed, 17 Jan 2024 19:28:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1EB56B009B; Wed, 17 Jan 2024 19:28:41 -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 8DFE46B0096 for ; Wed, 17 Jan 2024 19:28:41 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 62DB412093A for ; Thu, 18 Jan 2024 00:28:41 +0000 (UTC) X-FDA: 81690546042.04.42F878E Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by imf07.hostedemail.com (Postfix) with ESMTP id A3A4040007 for ; Thu, 18 Jan 2024 00:28:39 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=BedZH0wY; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705537719; a=rsa-sha256; cv=none; b=bAyxpR1Iibw3zhuSpwCU+v14/5L0wPBM1KwRHPY+T59lLh/SuRGSUoOMLm/lotrl1Xm0lc s0qj03n/Jw91ggeklxzTIxwTo5y7d7YdK8lSydxsIMl4OwUUhpodL8t5z2EIGSRvcGeg/c FM5guXDNssF2IJo8GvYq49HazEVPjPc= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=BedZH0wY; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.128.182 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=1705537719; 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=TY0wnVP2IVWwz/uO1z2ovVtLcTm9gQg3X53Rr9rGgIY=; b=79VTa3veWyfp/U9s9ftP027U/BxZlQDAGHpE/Nliyaaogr7jD67gV5p+nsrLyb0uRmDn7z KYxIt6m6T2nwTVifdDzfFEaXKTQtkc99fkjL/Xsfdw9v2hLA68NeqOI6XuVooFPwbe5Bm8 25Y2Qq8BRsVhQFLgdDdUrYJHBKJr3zc= Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-5eefd0da5c0so121174547b3.2 for ; Wed, 17 Jan 2024 16:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705537719; x=1706142519; 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=TY0wnVP2IVWwz/uO1z2ovVtLcTm9gQg3X53Rr9rGgIY=; b=BedZH0wYcqkxnV9QsgINMJcDepqKqCwOXp2NSx/6L21wC8KxDJ5YXLPPzIcPWzRcWh uHzYhnZTl2jXhIZNTS1i7SdCRxW1bdNhTGUFgPEFDo1QyfHYu9DQ0qXA4cYg48h59z42 VZWlzwsC7tJqAobmsX5gK9PV7JHxa3rEChAaayvVS2ZOmYnSufeZzrOK13FZOZMSqiGW Gc7XKac8rDcIsa99Y5858hPJnOXFc8VdGV7uh1dvJFIgEsWw9jtNwHDccbUnatH9vx9v OJxOJyK6mmTzTN4tcmdsAbxJtzlgQpUeG+D5jLq2Zu/sva8oNi+phE6RZfIIHCsV1TRe ZiSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705537719; x=1706142519; 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=TY0wnVP2IVWwz/uO1z2ovVtLcTm9gQg3X53Rr9rGgIY=; b=aYBYc37qiR+DdpBRSbpJ4idj3Mc7XGN7ie4XpUgCnd1k73ArmPCyR1L1kQAky3JaI+ r2QJysJwP9nkAPSEI4UhHYbxeloRapuPHXpLJfWDb8vwqcXmf9w+UAdd2rn5CYQlgCAh 2cjzBs6QZwqmHx/BxkVJ7uwo+ntPpFDb7y3YjjeVD8crdOEjWUyxRwqQQswAI3zGHxQE ehr8JaJyMJLG/sd93iIcZNVJtnxZTEz4rUziUth5pqoll3pHmsvboP+nqTWm84spijZp eRxMxXpBuopeJAR1qPFBfSGDk1lGkqk5eRJoW/fPBaSncmhLPT1mPTEaBp98vx2vPoV4 svkQ== X-Gm-Message-State: AOJu0Ywdw8iLGfTRnnya6/POMxImtv3g2dLZWGJISQNCITxqdDutxqWQ nULoJakPvIGrr72vAWWJ0FPBLNn5D4nMp5MlH8e9f8jhkhGiEwbkat4F03yqlXkbO271/w/bcZO Va0GLGnjhty1XYuhi1/3o4wpbmSrKUhvAH1O7mOvP3SwurTfrgw== X-Google-Smtp-Source: AGHT+IHPUIfgjLqHB+yEcEOpBY1uwAF24/DOg1T1dLE2qFz25IuG0GYLrSb6RCT8bk4nnZaTkSlUcKgc2cdTp1Pbgj4= X-Received: by 2002:a81:91c6:0:b0:5eb:5ebb:7155 with SMTP id i189-20020a8191c6000000b005eb5ebb7155mr57018ywg.15.1705537718591; Wed, 17 Jan 2024 16:28:38 -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:28:27 -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-Server: rspam08 X-Rspamd-Queue-Id: A3A4040007 X-Stat-Signature: a6qherisdkrnr3tugtftjg3dbyphi5fw X-Rspam-User: X-HE-Tag: 1705537719-170767 X-HE-Meta: U2FsdGVkX19/C36OZp7J9mF1F0w+wXAxyQYZqxKnBHCZjS2FtWHiE+9L2lHmTsbsYiFHFmkr/Lqs2swJEcbkB6Q8ceNktzRynCEm0iMWjDfqOmRu1M4o5rEhFoAEPp2nxdzcsMKKeTEQyrnNRGcRRP9Dk68kI6b026JkqKRzLwd2BL+Qk17Dv2/jYCNgZ3Qb3dlLN8a1l0g19gTd1W7y+q4F853jPciLsbpQk7tJ63NPlSf74/Liy+62R5sZGHvOY67W5nukGf9tslB71gEe4sr/IIEIUsKsMB7D6oo3hxo87OHyKxaw4OH8jA3vQOudys7KtgV8inFLSxy6cN+4tKjhYEEXG4fy7fWLQpZQvZTWsDGdpaYVUFHn/QRDEQ71HC4MttC2otvF9tHkDGI53ZIkznakjcogLBDNw7ieUZVUwZbWncfJEm8vpXeAOlO+Hru5yfrulIgJ7BOWRKwX6QwBOnvG6wSEEXVHRLEvHzHtqNfFKqakr6WVMmU8ONi54NAOez8c+8GbB7rouDBq8uhn4+Fy9qqtNnh51gz6NMg5+6RVxk3ijOSobMJHwQ4WgaPjny1QNnq2npKCDI6maugf8UVdWvslzCxJy3B8/8e/AFMSGsn19lW4s3mgfTENuQp2UYbciGrwyojVnGOEvlioBepHLhJokAq7xMT2JCuPTmzVa0JV0k1CW2+pgl9oVO6q+zLr3NfM9BJrUokPosCU6Y1KfNgsjXmq8qjF/WZkZPGSVZvAiQ0c4Ylwh5+M9qMuQwYtuZIJGfdukxAfW5EdfOrNo+/iV8M43FGJ+hMgL7F5oBfLCu/YjjnhHrZDNM3nkvwuTnsLVk3KSCQV2BGJwLWkujzOpqSIRB1yH5u66NZWsWJ0/NwWOGMttf65Ik2koIB8M+mfLB2KBIQ06cV6De9wFW0l1YjQk6gkG9/phS4Wput/18OkMfqZKSMjEKnAvsG62xi/XQ5u3jY +kt+09OA zi2v1DrTrIyAPBPaK3GfVIs/IdUDw9xrWqlT+2i9KQvcGCFYv7mcCpViFurPVwRfnYNoB/GQMxP6mjHfbpkQqCf+vi3RU9I4YnBTSIksD9ANqYPMLaIfGKVq+QUYtmvCqL8H+QD2r++N/7bNeR6b2n4s3+HywYtC2IG89ZY70sAiMsGE392NQRZE8gubeTL9rlkDKbSKwU/wxke+RsC7bCs+CaFxJWwA9Gy3w/DQ9IX7of4QvNdgXf2aNnOyndvyXDrEEvT7a1AYb6Hio8Yv4mIRhGaSwETpMNVsoN82Df209BNHgeaeQHDq6L4883/bctW5aBx+HGqoFC1ssi2BL48J5+etm4Kb9H/bMCsVyCzxY/zmjq7rwoXCYqV2uV0CBDZehuU2Q1CzAJ6QXqiN5FwzF+KdqPIMx2PXY7auHyeuf9bvTz2HOhVZ2CuQHes8MKkPtDWP/oQAPYQA= 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:15=E2=80=AFPM Yang Shi wrot= e: > > 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= _vmlinux.btf > > > > > > > > > > > > crashes or errors out with some random errors: > > > > > > [182671] STRUCT idr's field 'idr_next' offset=3D128 bit_size=3D= 0 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 a= llocate > > > > > > memory) > > > > > > > > > > > > Note the .tmp_vmlinux.btf above can be arbitrary, but likely la= rge > > > > > > 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, unsign= ed 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 TH= P > > > > > 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 emulat= ed 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. Oh, sorry, I didn't realize you were asking Jiri to test for the problem he reported :) > > > > > > > > > > > > > > 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 > > > > > > > > >