LinuxQuestions.org

LinuxQuestions.org (http://www.linuxquestions.org/questions/index.php)
-   Slackware (http://www.linuxquestions.org/questions/forumdisplay.php?f=14)
-   -   Dear Pat, please use the "CONFIG_HIGHMEM64G=yes" in the SMP kernel by default (http://www.linuxquestions.org/questions/showthread.php?t=794829)

LuckyCyborg 03-11-2010 06:09 PM

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!

modprob 03-11-2010 07:13 PM

Quote:

Originally Posted by LuckyCyborg (Post 3894967)
... because most users have 4, 8 or 16 gigabytes memory, today.

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

LuckyCyborg 03-11-2010 07:18 PM

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...

allend 03-11-2010 07:59 PM

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.

syg00 03-11-2010 08:03 PM

Quote:

Originally Posted by LuckyCyborg (Post 3895021)
A 64G enabled kernel will work fine even in a 128MB system, don't worry!

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 ...

escaflown 03-11-2010 08:06 PM

Quote:

Originally Posted by allend (Post 3895059)
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.

I second that

LuckyCyborg 03-11-2010 08:08 PM

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?

LuckyCyborg 03-11-2010 08:10 PM

Quote:

Originally Posted by syg00 (Post 3895061)
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 ...

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

T3slider 03-11-2010 08:25 PM

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?

LuckyCyborg 03-11-2010 08:36 PM

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?

amiga32 03-11-2010 09:42 PM

No.

Petri Kaukasoina 03-11-2010 11:23 PM

Quote:

Originally Posted by LuckyCyborg (Post 3895079)
Yep! Just to observe the DATE: Thu, 15 Nov 2007

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

Linus writes:

Quote:

So it's not "you can save a few instructions by not spilling to stack as much". It's a much bigger deal than that. There's a reason I personally refuse to even care about >2GB 32-bit machines. There's just no excuse these days to do that.

mudangel 03-11-2010 11:42 PM

Hey there, LuckyCyborg! You surely spew a lot of nonsense... such as:
Quote:

embarrassing (and ridiculous)
ok, how is that, exactly? And this bit:
Quote:

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?
makes almost no sense... to quote you, "So? What's the point?"

uppman 03-12-2010 02:05 AM

Quote:

Originally Posted by LuckyCyborg (Post 3895110)
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?

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

H_TeXMeX_H 03-12-2010 04:23 AM

Quote:

Originally Posted by syg00 (Post 3895061)
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 ...

Quote:

Originally Posted by Linus
So the _only_ explanation today for 12GB on a 32-bit machine is
(a) insanity
or
(b) being so lazy as to not bother to upgrade
and in either case, my personal reaction is "I'm *not* crazy, and yes, I'm
lazy too, and I can't give a rats *ss about those problems".

HIGHMEM was a mistake in the first place. It's one that we can live with,
but I refuse to support it more than it needs to be supported. And 12GB is
*way* past the end of what is worth supporting.

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


All times are GMT -5. The time now is 11:34 PM.