HLFS 64bit again

Rogelio M. Serrano Jr. rogelio at smsglobal.net
Wed Dec 26 20:41:23 PST 2007

goodoldmarty at gmail.com wrote:
> > Does it make sense to do that? PAE is not my favorite feature at all.
> > 64gb on a 32 bit arch is really a bad kludge. Its an unpopular feature
> > in linux already.
> You tell me. Anyone knows data fetches from memory, even using PAE are
> way faster than hitting a disk. No, the code is not efficient, but the
> same trick was done when 8 bit moved to 16, and 16 to 32, and is still
> done in all the 64 bit instructions today.
> Abstracting 2 discrete 32 bit CPU's to make 1 64 bit CPU is also just
> another kludge. The purpose is not related to performance. The purpose
> is to provide a migration path for marketing the first generation of
> real 64 bit processors. Without a codebase they have absolutely no
> market for their new chips.
> It's only about the greedy corporations getting rich using those
> marketing acronyms you so humorously embrace.
> > What are you using on your quad core? 32 bit linux and 32 bit userspace?
> 32 bit of course, and that is logical, but irrelevant. The quad is my
> workstation. I have 4-32 bit processors. They have large caches. I need
> 'only 4G' shared memory. I run a dist on it, not HLFS. Most of my linux
> apps are highly threaded. More execution units mean fewer context
> switches. This is efficient use of hardware, and runs way faster than if
> I was using apps compiled with any 64 bit toolchain.
> Marty B
sorry to beat on a dead horse but for the record i would like point
future questions on the subject to this thread:


quoting Alan Cox:

> ...but I've run into a situation in which a system on which I *have* set
> no overcommit is being blasted by the OOM killer anyway.

Looks like the kernel is eating all the resources needed.

>    Linux babyalcor #1 SMP Fri Oct 26 15:35:18 EDT 2007 \
>     i686 Dual Core AMD Opteron(tm) Processor 280 AuthenticAMD GNU/Linux

32bit kernel, 16GB of RAM. 

No suprise I'm afraid. Handling 16GB on a 32bit kernel, which has to
manage it all through a small addressible memory window is right on the
limit of what the standard kernel will handle (8GB is probably as high as
I would go). The no overcommit code ensures that user space doesn't
overcommit, but the kernel can get itself short of low memory resources
on a big box with 32bit kernels very easily. (In 64bit mode the CPU can
address all the memory directly so the problem vanishes).

You will *probably* get stable 16GB with the vendor tuned enterprise
kernels (RHEL, CentOS etc), or run a 64bit kernel and then the kernel
isn't trying the software equivalent of managing a filing cabinet through
the keyhole.

Democracy is about two wolves and a sheep deciding what to eat for dinner.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rogelio.vcf
Type: text/x-vcard
Size: 333 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20071227/3ef01894/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20071227/3ef01894/attachment.sig>

More information about the hlfs-dev mailing list