Re: Debian Lenny 32
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
Reply to: