[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac2e0f89-0aca-4038-877c-72b6ab8e53b9@kernel.org>
Date: Wed, 4 Sep 2024 08:06:17 +0200
From: Jiri Slaby <jirislaby@...nel.org>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Shung-Hsi Yu <shung-hsi.yu@...e.com>, dwarves@...r.kernel.org,
Jiri Olsa <olsajiri@...il.com>, masahiroy@...nel.org,
linux-kernel@...r.kernel.org, Nathan Chancellor <nathan@...nel.org>,
Nicolas Schier <nicolas@...sle.eu>, Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <martin.lau@...ux.dev>, Eduard Zingerman
<eddyz87@...il.com>, Song Liu <song@...nel.org>,
Yonghong Song <yonghong.song@...ux.dev>,
John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>,
linux-kbuild@...r.kernel.org, bpf@...r.kernel.org, msuchanek@...e.com
Subject: Re: [RFC] kbuild: bpf: Do not run pahole with -j on 32bit userspace
On 27. 08. 24, 10:37, Jiri Slaby wrote:
> On 26. 08. 24, 19:03, Arnaldo Carvalho de Melo wrote:
>> On Mon, Aug 26, 2024 at 10:57:22AM +0200, Jiri Slaby wrote:
>>> On 22. 08. 24, 17:24, Arnaldo Carvalho de Melo wrote:
>>>> On Thu, Aug 22, 2024 at 11:55:05AM +0800, Shung-Hsi Yu wrote:
>>>> I stumbled on this limitation as well when trying to build the
>>>> kernel on
>>>> a Libre Computer rk3399-pc board with only 4GiB of RAM, there I just
>>>> created a swapfile and it managed to proceed, a bit slowly, but worked
>>>> as well.
>>>
>>> Here, it hits the VM space limit (3 G).
>>
>> right, in my case it was on a 64-bit system, so just not enough memory,
>> not address space.
>>>> Please let me know if what is in the 'next' branch of:
>>
>>>> https://git.kernel.org/pub/scm/devel/pahole/pahole.git
>>
>>>> Works for you, that will be extra motivation to move it to the master
>>>> branch and cut 1.28.
>>
>>> on 64bit (-j1):
>>> * master: 3.706 GB
>>> (* master + my changes: 3.559 GB)
>>> * next: 3.157 GB
>>> on 32bit:
>>> * master-j1: 2.445 GB
>>> * master-j16: 2.608 GB
>>> * master-j32: 2.811 GB
>>> * next-j1: 2.256 GB
>>> * next-j16: 2.401 GB
>>> * next-j32: 2.613 GB
>>>
>>> It's definitely better. So I think it could work now, if the thread
>>> count
>>> was limited to 1 on 32bit. As building with -j10, -j20 randomly fails on
>>> random machines (32bit processes only of course). Unlike -j1.
>>
>> Cool, I just merged a patch from Alan Maguire that should help with the
>> parallel case, would be able to test it? It is in the 'next' branch:
>
> Not much helping.
>
> On my box (as all previous runs):
> next-j1 2.242
> next-j16 2.808
> next-j32 2.646
>
> On a build host:
> next-j1: 2.242
> next-j16: 2.824
> next-j20: 2.902 (crash)
> next-j32: 2.902 (crash)
So I disabled BTF on all 32bits (arm+i586) in openSUSE Tumbleweed for
now. Better kernel without BTF, than no kernel at all 8-).
If you have ideas to force -j1 on 32bit, I can reenable/retest...
thanks,
--
js
suse labs
Powered by blists - more mailing lists