[EMAIL PROTECTED] 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:
http://lkml.org/lkml/2007/12/17/7 http://lkml.org/lkml/2007/12/17/115 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 2.6.23.1 #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.
begin:vcard fn:Rogelio M. Serrano Jr n:M. Serrano Jr;Rogelio org:SMSG Communications Philippines;Technical Department adr:;;;;;;Republic of the Philippines email;internet:[EMAIL PROTECTED] title:Programmer tel;work:+6327534145 tel;home:+6329527026 tel;cell:+639209202267 x-mozilla-html:FALSE version:2.1 end:vcard
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
