* Jakob Oestergaard ([email protected]) wrote: > This is really the clever way to run a 64-bit system - 99% of what is > commonly run on most systems only gains overhead from the 64-bit address > space - tools like postfix, cron, syslog, apache, ... will not gain from > being native 64-bit. For most 64-bit systems, sure. For amd64 it's a little different because there are additional changes to the architecture (as compared to ia32/x86) which can more than make up for the difference for many applications. Then there's also things like encryption (postfix/tls, apache/ssl, etc) which can benefit greatly from better handling of 64bit (and larger) types. So, basically, it's not nearly so clear-cut as you portray it. :) > Solaris has done this for ages - maintaining a mostly 32-bit user space, > a 64-bit kernel, and then allowing for certain memory intensive > applications to run natively 64-bit. The differences between a 64bit sparc chip in 32bit and 64bit are quite a bit less than the differences between an amd64 chip in 32bit and 64bit. Thus, this makes alot more sense for sparc. > It's a nice way to run a Linux based system too, IMO. Perhaps on sparc or mips; it's much less clear-cut on amd64. Stephen
Attachment:
signature.asc
Description: Digital signature
- References:
- 10 GB in Opteron machine
- From: Christoph Pleger <[email protected]>
- Re: 10 GB in Opteron machine
- From: Jeff Garzik <[email protected]>
- Re: 10 GB in Opteron machine
- From: Christoph Pleger <[email protected]>
- Re: 10 GB in Opteron machine
- From: Jakob Oestergaard <[email protected]>
- 10 GB in Opteron machine
- Prev by Date: Re: [linux-pm] [PATCH] Syncthreads support.
- Next by Date: Re: Kernel cached memory
- Previous by thread: Re: 10 GB in Opteron machine
- Next by thread: Re:=?iso-8859-1?Q?[COMPILE_ERROR]_realtime-preempt-2=2E6=2E12-final-V0=2E7=2E51-33_on_x86_64_SMP_system
- Index(es):