Dear Pat, please use the "CONFIG_HIGHMEM64G=yes" in the SMP kernel by default
 

... because most users have 4, 8 or 16 gigabytes memory, today.

It's embarrassing (and ridiculous) to recompile the kernel every time when you do upgrade, because it recognizes only 2GB of the 4GB that are on my system. ;-)

Thanks!

That is debatable. Remember that one of the advantages of Slackware is the ability to run out of the box on older systems.

A 64G enabled kernel will work fine even in a 128MB system, don't worry!

Also, just to observe that I suggest this option for SMP systems... I.e. a Phenom X4, that can't be considered today a older box, BUT is so OLD...

Hmm - I have six boxes running Slackware and the RAM ranges from 128MB to 1GB. On your shiny new box, compiling a Kernel probably takes less than 10 minutes, whereas for me to revert from your bloat suggestion to free up precious RAM would take significantly longer than that.
What do you do that requires greater than 2GB RAM?
A big 'No Thanks' from me.

FSVO "fine".
Big memory on 32-bit systems is (these days) a losing argument. Page tables (and other control blocks) have to be built, PAE support is a kludge ...
Why subject every user to this for the few ?.

Here's what Linus thinks on the subject ...

I second that

Suppose a system is typical for Gammers, i.e. to have Windows 7 and 8 GB RAM ...

Anyways, What is your problem, if you will not notice any difference with 64G enabled kernels?

Yep! Just to observe the DATE: Thu, 15 Nov 2007

Why not come into the 21st century and get a 64-bit capable CPU if you have that much RAM?

If I am running a 32-bit OS (slack) on my old 333 MHz box as a server, with 256 MB RAM, I want it as light as possible. HIGHMEM64G support is certainly added cruft that I don't need or want.

On my current box I run Slackware64-13.0, and this silly HIGHMEM64G nonsense is moot. And what kind of gamer has a CPU that isn't capable of 64-bit processing? The first AMD64 chip was released in 2003, 7 years ago. That is much older than that post (not even 3 years) that you think is now garbage. All remotely recent intel and AMD chips are x86_64, and you can just go multilib if you want 32-bit programs as well. Or just compile the kernel yourself, which doesn't take long. The defaults in the kernel are there for a reason -- I know I wouldn't want needless code enabled on my old server, which would take hours to recompile the kernel.

You seem to criticize everyone else's posts as if they are *totally* invalid. You have one opinion, others have theirs and most here have backed up their opinion with valid reasons. It's a divisive option, clearly, so why not be conservative and let those with faster CPUs recompile instead of those with slower ones?

I have 64-bit capable CPU in every system. I.e. it's a "AMD Phenom(tm) 9650 Quad-Core Processor" in the "home box".

BUT! I simple need to use the bare 32 bits operating systems. For business reasons. Call me conservative, but a HIGHMEM64G enabled SMP kernel have no impact to (poor) users with 128MB memory.

It's verified hundred times. So? What's the point?

No.

This is newer (10 Oct 2009):
http://article.gmane.org/gmane.linux.kernel/900604

Linus writes:

Hey there, LuckyCyborg! You surely spew a lot of nonsense... such as: ok, how is that, exactly? And this bit:makes almost no sense... to quote you, "So? What's the point?"

You could try 64-bit with AlienBob's multilib for the 32-bit parts..

Ahh, it's always fun to read Linus T's opinions. And, I agree with him :)