You are not logged in.

#1 2024-11-01 02:57:34

Bob Hill
Member
From: Wollerau, Switzerland
Registered: 2019-05-30
Posts: 17

Re-organize PAE and non-PAE kernels?

This topic is related to five-year-old topic: https://bbs.archlinux32.org/viewtopic.php?id=2462

What if:
1. Arch Linux 32 would build kernels in package "linux" without PAE for i486 (as is), and (new) with PAE for i686 and pentium4;
and:
2. Arch Linux 32 would scrap package "linux-pae" entirely (it appears to be out-of-date anyway - currently 6.2 versus 6.11.3).

Proposed advantages:
a. i686 and pentium4 users with more than 4GB RAM would then get up-to-date PAE kernels.
(i686 and pentium4 users with 4GB or less RAM would still run fine despite then getting PAE kernels - other 32-bit distributions have been doing this for years - see: https://en.wikipedia.org/wiki/Physical_ … sion#Linux .)
and:
b. One less package ("linux-pae") to maintain.

Offline

#2 2024-11-01 09:50:58

abaumann
Administrator
From: Zurich
Registered: 2019-11-14
Posts: 1,042
Website

Re: Re-organize PAE and non-PAE kernels?

The main reason for having split linux and linux-pae are there are systems supporting i686 and pentium4 (mainly embedded things) which
will never have close to 4 GB of RAM (think an Alix board with 256 MB RAM). PAE is a property of the kernel being built and not of the
subarchitecture being supported. OTOH I agree things should be up- to-date and could share a common configuration, being patched
in the miniconfig-style.

Offline

#3 2024-11-02 09:37:39

Bob Hill
Member
From: Wollerau, Switzerland
Registered: 2019-05-30
Posts: 17

Re: Re-organize PAE and non-PAE kernels?

Many thanks for your clarification. In what timeframe do you think  it might be possible to get packages "linux" and "linux-pae" to share a common configuration, so that both are equally up-to-date?

Offline

#4 2024-12-19 01:44:26

liewkj
Member
Registered: 2020-04-15
Posts: 35

Re: Re-organize PAE and non-PAE kernels?

abaumann wrote:

The main reason for having split linux and linux-pae are there are systems supporting i686 and pentium4 (mainly embedded things) which
will never have close to 4 GB of RAM (think an Alix board with 256 MB RAM).

IIRC, PAE is required to support NX for system with less then 4GB of RAM, hence more secured and hardened kernel for modern 32-bit x86 systems. I strongly recommend that `linux` should just be PAE enabled for the sake of NX and dropping the need for a separate `linux-pae`.

Debian i386 is doing the same and always ships with PAE-enabled kernel.

Offline

#5 2024-12-20 11:57:51

Bob Hill
Member
From: Wollerau, Switzerland
Registered: 2019-05-30
Posts: 17

Re: Re-organize PAE and non-PAE kernels?

liewkj, Thank you for your input. AFAIK a PAE-kernel requires a PAE-capable CPU, which is why I originally suggested building kernels in package "linux" without PAE for "i486" CPUs (which may not be PAE-capable), and with PAE for "i686" and "pentium4" CPUs (which can be expected to be PAE-capable).

Offline

#6 2024-12-20 21:50:14

liewkj
Member
Registered: 2020-04-15
Posts: 35

Re: Re-organize PAE and non-PAE kernels?

Hi Bob, I strongly agree with your suggestion and it makes sense to do so since `linux-pae` package has been purged and out of maintained.

Though glancing at the PKGBUILD source files, it is even possible to keep "non-PAE" for i486 and i686 while always have "PAE-enabled" for pentium4. And here's the only change required for config.pentium4.

-CONFIG_HIGHMEM4G=y
-# CONFIG_HIGHMEM64G is not set
+# CONFIG_HIGHMEM4G is not set
+CONFIG_HIGHMEM64G=y

Offline

#7 2024-12-21 09:44:15

Bob Hill
Member
From: Wollerau, Switzerland
Registered: 2019-05-30
Posts: 17

Re: Re-organize PAE and non-PAE kernels?

liewkj, Thank you very much for your support. Now we only have a slight difference of opinion:

You suggest building non-PAE kernels for "i486" and "i686" CPU's, and building PAE kernels for "pentium4" CPU's;

I suggest building non-PAE kernels for "i486" CPU's, and building PAE kernels for "i686" and "pentium4" CPU's.

What do you think about this difference of opinion regarding non-PAE versus PAE kernels for "i686" CPU's?

Offline

#8 2024-12-22 00:12:42

liewkj
Member
Registered: 2020-04-15
Posts: 35

Re: Re-organize PAE and non-PAE kernels?

Bob Hill wrote:

What do you think about this difference of opinion regarding non-PAE versus PAE kernels for "i686" CPU's?

It is to offer an option for those who insist PAE as bloat and slow down their systems due to additional page-walk and memory for page tables. IMHO, having NX protection is most critical and it should have outweighed the 2~5% performance impact from PAE. Windows XP SP3 also always has PAE enabled for NX regardless of installed RAM size.

There is literally no difference in config.i686 and config.pentium4, so logically config.pentium4 can be made PAE-enabled while keeping config.i686 for those with old CPUs regardless of PAE capability.

Offline

#9 2024-12-22 13:37:37

Bob Hill
Member
From: Wollerau, Switzerland
Registered: 2019-05-30
Posts: 17

Re: Re-organize PAE and non-PAE kernels?

liewkj, Thank you again for your prompt input. Going right back to square one, there might still be some merit in leaving package "linux" without PAE for i486/i686/pentium4 (as it is), and maintaining package "linux-pae" with PAE for i686/pentium4 (as it is), but keeping package "linux-pae" up-to-date. That way users can themselves choose whether to install a non-PAE kernel or an up-to-date PAE kernel. This would seem to be a more flexible solution than what we have been discussing so far, because users get to choose whether non-PAE or PAE kernel, rather than being forced into one or the other according to their pacman-specified i486/i686/pentium4 status.

Last edited by Bob Hill (2024-12-22 14:10:08)

Offline

#10 2024-12-24 02:20:17

liewkj
Member
Registered: 2020-04-15
Posts: 35

Re: Re-organize PAE and non-PAE kernels?

Bob, you're welcome, it was an ideal situation that I don't disagree with you. Unfortunately, in reality this distro is strapped on both human & machine resources. One less package to build & maintain is simpler for easing things up.

Offline

Board footer

Powered by FluxBB