info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Ability to further support 32bit architectures
17 views
Skip to first unread message
Dimitri John Ledkov
Jan 11, 2024, 4:50:05 AMJan 11
to
Hi,
On Thu, 11 Jan 2024 at 09:42, Bastian Blank <wa...@debian.org> wrote:
>
> Hi
>
> Linux 6.7 fails to build on at least i386 and armhf. Even it now
> manages to make the compiler fail to allocate memory:
> | cc1: out of memory allocating 135266296 bytes after a total of 235675648 bytes
>
> Right now both fail on the same driver, so a short team workaround would
> be to disable it. But we need a long term fix, and quickly.
>
> As it is now, we will not be able to provide a kernel for maybe all
> 32bit architectures for Trixie.
>
> Bastian
>
Disabling debug symbols, enabling debug symbol zstd compression, using
split debug symbols (disabled BTF usage) should help here.
Separately, I wish we had cross-builders available, and cross-build
i386/armhf kernels from amd64/arm64 and thus having access to 64-bit
compiler.
I am experiencing the same issue with the armhf kernels on my infrastructure.
--
Dimitri
Sent from Ubuntu Pro
https://ubuntu.com/pro
On Thu, 11 Jan 2024 at 09:42, Bastian Blank <wa...@debian.org> wrote:
>
> Hi
>
> Linux 6.7 fails to build on at least i386 and armhf. Even it now
> manages to make the compiler fail to allocate memory:
> | cc1: out of memory allocating 135266296 bytes after a total of 235675648 bytes
>
> Right now both fail on the same driver, so a short team workaround would
> be to disable it. But we need a long term fix, and quickly.
>
> As it is now, we will not be able to provide a kernel for maybe all
> 32bit architectures for Trixie.
>
> Bastian
>
Disabling debug symbols, enabling debug symbol zstd compression, using
split debug symbols (disabled BTF usage) should help here.
Separately, I wish we had cross-builders available, and cross-build
i386/armhf kernels from amd64/arm64 and thus having access to 64-bit
compiler.
I am experiencing the same issue with the armhf kernels on my infrastructure.
--
Dimitri
Sent from Ubuntu Pro
https://ubuntu.com/pro
Bastian Blank
Jan 11, 2024, 4:50:05 AMJan 11
to
Hi
Linux 6.7 fails to build on at least i386 and armhf. Even it now
manages to make the compiler fail to allocate memory:
| cc1: out of memory allocating 135266296 bytes after a total of 235675648 bytes
Right now both fail on the same driver, so a short team workaround would
be to disable it. But we need a long term fix, and quickly.
As it is now, we will not be able to provide a kernel for maybe all
32bit architectures for Trixie.
Bastian
--
Linux 6.7 fails to build on at least i386 and armhf. Even it now
manages to make the compiler fail to allocate memory:
| cc1: out of memory allocating 135266296 bytes after a total of 235675648 bytes
Right now both fail on the same driver, so a short team workaround would
be to disable it. But we need a long term fix, and quickly.
As it is now, we will not be able to provide a kernel for maybe all
32bit architectures for Trixie.
Bastian
No one can guarantee the actions of another.
-- Spock, "Day of the Dove", stardate unknown
Bastian Blank
Jan 11, 2024, 5:50:03 AMJan 11
to
On Thu, Jan 11, 2024 at 10:50:31AM +0100, John Paul Adrian Glaubitz wrote:
> > As it is now, we will not be able to provide a kernel for maybe all
> > 32bit architectures for Trixie.
> I don't think that this would be a reasonable decision. We're preparing to switch
> > As it is now, we will not be able to provide a kernel for maybe all
> > 32bit architectures for Trixie.
> 32-bit architectures over to time64_t. Disabling 32-bit kernel builds would make
> this whole work moot.
This is completely unrelated. Userland != kernel. And people already
talked about only supporting userland for those architectures.
> FWIW, both m68k and powerpc are not affected by this bug, the powerpc build fails
> because of a packaging problem.
Actually powerpc fails for exactly the same reason:
| cc1: out of memory allocating 135266296 bytes after a total of 244908032 bytes
| make[9]: *** [/<<PKGBUILDDIR>>/scripts/Makefile.build:248: drivers/media/pci/solo6x10/solo6x10-p2m.o] Error 1
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.7-1%7Eexp1&stamp=1704796355&raw=0
Bastian
--
Earth -- mother of the most beautiful women in the universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1
Bastian Blank
Jan 11, 2024, 5:50:04 AMJan 11
to
Hi
On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> Disabling debug symbols, enabling debug symbol zstd compression, using
> split debug symbols (disabled BTF usage) should help here.
Okay, maybe more workarounds exist. But none of them look really
promising.
> Separately, I wish we had cross-builders available, and cross-build
> i386/armhf kernels from amd64/arm64 and thus having access to 64-bit
> compiler.
Real cross-builders would use some fast amd64/arm64/ppc64el (and for
amd64 also reasonably cheap) machines to build all other architectures.
Bastian
--
You're dead, Jim.
-- McCoy, "Amok Time", stardate 3372.7
On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> Disabling debug symbols, enabling debug symbol zstd compression, using
> split debug symbols (disabled BTF usage) should help here.
promising.
> Separately, I wish we had cross-builders available, and cross-build
> i386/armhf kernels from amd64/arm64 and thus having access to 64-bit
> compiler.
amd64 also reasonably cheap) machines to build all other architectures.
Bastian
--
You're dead, Jim.
-- McCoy, "Amok Time", stardate 3372.7
Adrian Bunk
Jan 11, 2024, 6:50:04 AMJan 11
to
On Thu, Jan 11, 2024 at 11:28:19AM +0100, Bastian Blank wrote:
>...
gcc being a memory hog on for C++ code is a hard problem,
and debug symbols for C++ code can be a problem since
they might be > 1 GB for some binaries.
But gcc needing more than 4 GB for a small C kernel driver is not
a problem for the "Ability to further support 32bit architectures",
that's a gcc bug that should be reported upstream just like you wouldn't
suggest dropping amd64 if gcc would ICE on one kernel driver on that
architecture.
> Bastian
cu
Adrian
>...
> On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
>
> Okay, maybe more workarounds exist. But none of them look really
> promising.
>...
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
>
> Okay, maybe more workarounds exist. But none of them look really
> promising.
gcc being a memory hog on for C++ code is a hard problem,
and debug symbols for C++ code can be a problem since
they might be > 1 GB for some binaries.
But gcc needing more than 4 GB for a small C kernel driver is not
a problem for the "Ability to further support 32bit architectures",
that's a gcc bug that should be reported upstream just like you wouldn't
suggest dropping amd64 if gcc would ICE on one kernel driver on that
architecture.
> Bastian
cu
Adrian
Jeffrey Walton
Jan 11, 2024, 11:10:04 AMJan 11
to
On Thu, Jan 11, 2024 at 5:45 AM Bastian Blank <wa...@debian.org> wrote:
>
> On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
>
> Okay, maybe more workarounds exist. But none of them look really
> promising.
Also see <https://wiki.debian.org/ReduceBuildMemoryOverhead>.
>
> On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
>
> Okay, maybe more workarounds exist. But none of them look really
> promising.
> > Separately, I wish we had cross-builders available, and cross-build
> > i386/armhf kernels from amd64/arm64 and thus having access to 64-bit
> > compiler.
>
> Real cross-builders would use some fast amd64/arm64/ppc64el (and for
> amd64 also reasonably cheap) machines to build all other architectures.
Aurelien Jarno
Jan 11, 2024, 12:40:04 PMJan 11
to
https://lore.kernel.org/lkml/CAHk-=whkGHOmpM_1kNgzX1UDAs10+UuALcpeEWN29EE0m-my=w...@mail.gmail.com/
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aure...@aurel32.net http://aurel32.net
YunQiang Su
Jan 12, 2024, 11:20:04 AMJan 12
to
<rh...@neoquasar.org> 于2024年1月12日周五 23:59写道：
>
> Keeping in mind that I am new to this arena...
>
> I have some Intel systems - both 64-bit and 32-bit - that I might be able to use as build platforms.
>
I guess all of your hardwares are 64bit. You setup different OS on them.
> What does the Debian team need from me to be able to use these systems?
>
It's not about performance of hardware. It is about some limitation of 32bit.
2 examples for it:
1. if we use 32bit value for time, it will overflow in 2038, then
your time will be shown as 1900.
https://en.wikipedia.org/wiki/Year_2038_problem
2. A single process (or maybe APP, not precisely), can only use UP
to 4GiB RAM.
In fact on most system the value is less than 4GiB:
on intel32, it is 3GiB
on mips32, it is 2GiB
But currently, it is not enough, for example, when we build a
big APP, it will need much more RAM.
The RAM does install in your Rack, but you can NOT use it.
https://en.wikipedia.org/wiki/3_GB_barrier
> I can't guarantee they'll be FAST, but I'll do what I can to make them EFFECTIVE.
>
If you are really need 32bit system. Maybe you can say out why you
*REALLY* need it.
For most users, the suggestion is: upgrade to 64bit.
> --J
>
>
> Keeping in mind that I am new to this arena...
>
> I have some Intel systems - both 64-bit and 32-bit - that I might be able to use as build platforms.
>
I guess all of your hardwares are 64bit. You setup different OS on them.
> What does the Debian team need from me to be able to use these systems?
>
It's not about performance of hardware. It is about some limitation of 32bit.
2 examples for it:
1. if we use 32bit value for time, it will overflow in 2038, then
your time will be shown as 1900.
https://en.wikipedia.org/wiki/Year_2038_problem
2. A single process (or maybe APP, not precisely), can only use UP
to 4GiB RAM.
In fact on most system the value is less than 4GiB:
on intel32, it is 3GiB
on mips32, it is 2GiB
But currently, it is not enough, for example, when we build a
big APP, it will need much more RAM.
The RAM does install in your Rack, but you can NOT use it.
https://en.wikipedia.org/wiki/3_GB_barrier
> I can't guarantee they'll be FAST, but I'll do what I can to make them EFFECTIVE.
>
If you are really need 32bit system. Maybe you can say out why you
*REALLY* need it.
For most users, the suggestion is: upgrade to 64bit.
> --J
>
Alan Corey
Jan 12, 2024, 1:30:04 PMJan 12
to
Are you forgetting that 64 bit is slower? In the arm world where it's easily switchable 64 bit is pokey when you don't need it.
On Fri, Jan 12, 2024, 12:54 PM <rh...@neoquasar.org> wrote:
Sent from my mobile device.From: YunQiang Su <wzs...@gmail.com>
Sent: Friday, January 12, 2024 10:11
To: rh...@neoquasar.org
Cc: nolo...@gmail.com; debian...@lists.debian.org; debia...@lists.debian.org; debian...@lists.debian.org; debian-...@lists.debian.org
Subject: Re: Ability to further support 32bit architectures
<rh...@neoquasar.org> 于2024年1月12日周五 23:59写道：
>
> Keeping in mind that I am new to this arena...
>
> I have some Intel systems - both 64-bit and 32-bit - that I might be able to use as build platforms.
>
I guess all of your hardwares are 64bit. You setup different OS on them.
No. I have multiple 32-bit systems, one of which is Intel.
> What does the Debian team need from me to be able to use these systems?
>
It's not about performance of hardware. It is about some limitation of 32bit.
2 examples for it:
1. if we use 32bit value for time, it will overflow in 2038, then
your time will be shown as 1900.
https://en.wikipedia.org/wiki/Year_2038_problem
2. A single process (or maybe APP, not precisely), can only use UP
to 4GiB RAM.
In fact on most system the value is less than 4GiB:
on intel32, it is 3GiB
on mips32, it is 2GiB
But currently, it is not enough, for example, when we build a
big APP, it will need much more RAM.
The RAM does install in your Rack, but you can NOT use it.
https://en.wikipedia.org/wiki/3_GB_barrier
> I can't guarantee they'll be FAST, but I'll do what I can to make them EFFECTIVE.
>
If you are really need 32bit system. Maybe you can say out why you
*REALLY* need it.
For most users, the suggestion is: upgrade to 64bit.
That's not at all what I was asking or talking about.--J
gene heskett
Jan 12, 2024, 1:40:04 PMJan 12
to
On 1/12/24 13:07, Alan Corey wrote:
> Are you forgetting that 64 bit is slower? In the arm world where it's
> easily switchable 64 bit is pokey when you don't need it.
>
Thank Alan, to put numbers behind that, linuxcnc has a thing called
> Are you forgetting that 64 bit is slower? In the arm world where it's
> easily switchable 64 bit is pokey when you don't need it.
>
latency-test on an rpi4b the armhf kernel I built from 4.19 srcs, can
respond to an irq in 12 microseconds, this in 2018. in 2023, an arm64
rt-preempt kernel can only do that in around 50 microseconds. The huge
majority of that time is a increased size of the stack frame it has to
put away and then reload the environment to handle the interrupt.
> On Fri, Jan 12, 2024, 12:54 PM <rh...@neoquasar.org
> <mailto:rh...@neoquasar.org>> wrote:
>
>
>
> Sent from my mobile device.
>
> *From:* YunQiang Su <wzs...@gmail.com <mailto:wzs...@gmail.com>>
> *Sent:* Friday, January 12, 2024 10:11
> *To:* rh...@neoquasar.org <mailto:rh...@neoquasar.org>
> *Cc:* nolo...@gmail.com <mailto:nolo...@gmail.com>;
> debian...@lists.debian.org
> <mailto:debian...@lists.debian.org>; debia...@lists.debian.org
> <mailto:debia...@lists.debian.org>; debian...@lists.debian.org
> <mailto:debian...@lists.debian.org>;
> debian-...@lists.debian.org <mailto:debian-...@lists.debian.org>
> *Subject:* Re: Ability to further support 32bit architectures
>
> <rh...@neoquasar.org <mailto:rh...@neoquasar.org>> 于2024年1月12日周五
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Bastian Blank
Jan 12, 2024, 5:40:05 PMJan 12
to
On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> Disabling debug symbols, enabling debug symbol zstd compression, using
> split debug symbols (disabled BTF usage) should help here.
Disabling debug symbols does not help.
> split debug symbols (disabled BTF usage) should help here.
Bastian
Just curious why you send ads?
--
Immortality consists largely of boredom.
-- Zefrem Cochrane, "Metamorphosis", stardate 3219.8
Alan Corey
Jan 12, 2024, 6:10:03 PMJan 12
to
So, can you set an RPI4 to 32 bit for even more speed?
My Pi4 config.txt (Debian Bookworm) says
# Switch the CPU from ARMv7 into ARMv8 (aarch64) mode
arm_64bit=1
I haven't tried it because I don't know how the software will handle the timing.
-------------
Education is contagious.
Education is contagious.
Hank Barta
Jan 12, 2024, 6:30:04 PMJan 12
to
On Fri, Jan 12, 2024 at 5:07 PM Alan Corey <alan...@gmail.com> wrote:
>
> So, can you set an RPI4 to 32 bit for even more speed?
> My Pi4 config.txt (Debian Bookworm) says
>
> # Switch the CPU from ARMv7 into ARMv8 (aarch64) mode
> arm_64bit=1
>
You would have to try it to see if it is faster for your workload. I
>
> So, can you set an RPI4 to 32 bit for even more speed?
> My Pi4 config.txt (Debian Bookworm) says
>
> # Switch the CPU from ARMv7 into ARMv8 (aarch64) mode
> arm_64bit=1
>
suspect that the context switch is faster because there are fewer
registers to save/restore and they are 32 bit vs. 64 bit. Addresses
are also 32 bit, requiring less to load from RAM. (And I am not
familiar with ARM addressing modes so there may well be relative
addresses that allow shorter addresses in 64 bit mode.) I also wonder
about differences in CPU cache between 32 and 64 bit mode. Some of
these things slow specific operations while others (such as more
registers) can improve performance.
There's probably other stuff I'm not aware of that affects performance
comparisons between 64 and 32 bit mode.
--
Beautiful Sunny Winfield
Dimitri John Ledkov
Jan 13, 2024, 11:40:04 AMJan 13
to
Heya,
On Fri, 12 Jan 2024, 22:36 Bastian Blank, <wa...@debian.org> wrote:
On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> Disabling debug symbols, enabling debug symbol zstd compression, using
> split debug symbols (disabled BTF usage) should help here.
Disabling debug symbols does not help.
This now smells a lot more like an actual bug in either kernel source code, or compiler, or both. Rather than natural growth and actually needing that much memory. Probably worth escalating.
Felt cute, might remove later.
Bastian Blank
Jan 13, 2024, 12:00:04 PMJan 13
to
On Sat, Jan 13, 2024 at 04:31:35PM +0000, Dimitri John Ledkov wrote:
> On Fri, 12 Jan 2024, 22:36 Bastian Blank, <wa...@debian.org> wrote:
> > On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> > > Disabling debug symbols, enabling debug symbol zstd compression, using
> > > split debug symbols (disabled BTF usage) should help here.
> > Disabling debug symbols does not help.
> This now smells a lot more like an actual bug in either kernel source code,
> or compiler, or both. Rather than natural growth and actually needing that
> much memory. Probably worth escalating.
What actually helps is -ftrack-macro-expansion=1.
> On Fri, 12 Jan 2024, 22:36 Bastian Blank, <wa...@debian.org> wrote:
> > On Thu, Jan 11, 2024 at 09:48:34AM +0000, Dimitri John Ledkov wrote:
> > > Disabling debug symbols, enabling debug symbol zstd compression, using
> > > split debug symbols (disabled BTF usage) should help here.
> > Disabling debug symbols does not help.
> This now smells a lot more like an actual bug in either kernel source code,
> or compiler, or both. Rather than natural growth and actually needing that
> much memory. Probably worth escalating.
https://salsa.debian.org/kernel-team/linux/-/merge_requests/998
Bastian
--
The joys of love made her human and the agonies of love destroyed her.
-- Spock, "Requiem for Methuselah", stardate 5842.8
Aurelien Jarno
Jan 13, 2024, 1:50:05 PMJan 13
to
https://lore.kernel.org/lkml/20240113183334.1...@aurel32.net/T/#u
0 new messages