[Gllug] 4G Memory Restriction
Christian Smith
csmith at micromuse.com
Mon Apr 10 15:21:46 UTC 2006
On Mon, 10 Apr 2006, Alain Williams wrote:
>On Mon, Apr 10, 2006 at 02:26:56PM +0100, Tet wrote:
>> On 4/10/06, Daniel P. Berrange <dan at berrange.com> wrote:
>>
>> >You still really really want to use 64-bit kernel & OS if at all
>> possible though.
>>
>> Note that this only applies to x86 compatible chips. On sparc64, it
>> turned out to be quite a big win to stick with a 32-bit userland with
>> a 64-bit kernel, unless your application *needed* to be 64-bit (large
>> databases and the like).
>
>I guess that this is because 64 bit programs are bigger & use more
>dataspace, this means that the programs do not fit so nicely into CPU
>cache. Is that correct ?
Yes. 32 bit apps will generally have a smaller working set than equivalent
64 bit apps. But the bloat may not be that significant, as a lot of
transient data will be held in CPU registers, and not touch RAM at all.
Benefits of RISC CPUs large register sets are magnified with a good
compiler.
>
>But, if you run both 32 & 64 bit programs on your box you are going to
>need to have 2 copies of the C library (& others) in RAM.... it gets
>complicated.
>
Not complicated. You just have essentially two copies of the same
libraries in memory. The kernel just tracks them as files, and doesn't
care. No more complex than tracking any two different files.
The only waste is that you'll now have two copies (if you actually mix
64 and 32 bit apps) of the userland runtime. This won't be much of an
issue because:
- You have gobs of RAM anyway, else you wouldn't be running 64 bit
anything.
- Cache usage is so localised temporally that having the impact
of copies of libraries should be minimal.
But if you don't have any apps that run 64-bit, you won't have any of the
above issues anyway, but still have the benfits of a 64 bit kernel.
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
--
Gllug mailing list - Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
More information about the GLLUG
mailing list