On Fri, 30 Dec 2011 12:25:21 -0700, Bob Proulx wrote: > Camaleón wrote: >> Stan Hoeppner wrote: >> > Camaleón wrote: >> >> Mohamed Daif wrote: >> >>> What is the maximum RAM supported in Debian Lenny 32bit . >> >> >> >> It should be 64 GiB with a PAE enabled kernel (bigmem). >> > >> > 64GB max for the kernel, but userspace processes are still limited to >> > a 4GB virtual address space. Thus if one has an application, say a >> > database or medical imaging app (think MRI), that requires direct >> > access to say, 32GB of RAM, one should be using an x86-64 kernel and >> > an application compiled for an x86-64 target. >> >> That's a self-imposed limitation. > > What is self-imposed? 4GB of virtual address space? That is the > definition of a 32-bit address space. It is only self imposed if you > include choosing a 32-bit architecture in the choice. And actually > unless you do special things you really will be limited to 3G. (It used > to be that you couldn't get above 2G without linking with -N. But things > have been rewritten to make 3G the default now.) Going to 64-bits is > the much easier way to make use of a large memory space.
Yes, I do know. It can be still useful under determined scenarios to be able to map as much ram as you can, i.e., for databases. >> It could be by-passed by using "memory mapping" techniques (this is >> documented in the wikipedia page you pointed out about PAE, which >> specifically mentions "mmap()") but not many linux applications are >> making use of it, I'm afraid, contrary what happens on Windows systems. > > None of that is real memory. Even if an application codes in the > ability to use application level paging to handle more data the program > itself is still limited to 32-bits. That's what memory mapping is for and that's what PAE does at a different level. Being convenient or not, being real or virtual it's an option for 32-bits systems that need to handle big amounts of data, system wide or per-process. > (There are a lot of wonderful Seymour Cray quotes, or at least > attributions to him even if he didn't actually say them, that I really > wanted to say here about memory. Consider this an "in" joke for > everyone who knows what I am talking about. I will leave with this one: > "Virtual memory leads to virtual performance.") I personally don't like how PAE nor mmap() do they work. They are by- passes, "patches" but not a real solution to the problem. Yes, there are noticeable penalties for a system starting from 8 GiB of RAM when using PAE (this was discussed on the kernel mailing lists a year or so ago), but I'm not judging if this (PAE, mmap...) is convenient or not just point there are ways to remove the 4 GiB pero process restriction. Whether this is optimal or not is another issue. >> In the end, applications that need to handle/move big quantities of >> data directly from the RAM will benefit of a pure 64-bits OS. > > Agreed. But I don't think we have gotten to the point where most > desktop users need it yet. *Wanting* it is fine though. But even most > people's pig applications of libreoffice and firefox don't usually need > more than 3G of memory. But of course if there is any application > (usually scientific or some other technical domain) that needs more than > 3G of data space then they really do need a 64-bit architecture. They > usually already know who they are. Yes, I do also think so. Infact, I've got the impression we do not either need such powerful systems for evey user and every mundane task, a Pentium III is still perfect capable of doing 70% of a default user dayly work :-) But one of the "pros" of encouraging people to jump to 64-bits based applications/OSes is that programmers and developers had to do the coding work to adapt the programs to the 64-bits arquitecture and now there not many applications that cannot be run on the new platform. There is always side benefits... Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.12.31.10.39...@gmail.com