I wrote:
> However, if the program is dynamically linked, it will need 32 bit
> versions of the libraries. Now some of these libraries will probably
> already be loaded, but on a 64 bit OS, they might well be 64 bit
> versions. So the kernel will probably have to keep 32 bit and 64 bit
> versions of the same libraries loaded. This reduces the efficiency of
> the CPU's caches, and makes less RAM available for hard disk caching.
Thomas Zehetbauer wrote:
> You mean I/O cache, not CPU cache, libraries are loaded into the address
> space of every application and not shared in memory, at least not with
> Linux.
I meant what I wrote, but I possibly over-simplified...
First let me note that libraries are *both* "loaded into the address
space of every application" and "shared in memory". A process' address
space, its view of how memory is laid out, bears no relationship to
reality.
Memory is divided into 4K pages: some of the pages in its address space
will be mapped to real memory (normally *not* contiguous memory). Some
may be mapped to pages in the swap file. And there are a number of other
ways that pages might be handled. This mapping is done by a combination
of the MMU, the Memory Management Unit in the CPU, and the virtual
memory subsystem of the kernel.
So (pages from) a library would be loaded from disk into real RAM, and
then mapped into the address space of each process that used the
library. Each process would "think" that it had sole access to the
library: if it needed to write to any of those pages, a Copy On Write
would occur, and a modifiable copy of just that page would be created
just for that process.
Back towards your point: at least the second level CPU cache stores data
based on real addresses, not the address space addresses. So, just as
the underlying memory page could be a library loaded into several
hundred processes, so the cache line would provide data from that page
to any of those several hundred processes. The library would only appear
in memory once, or in that cache once.
Obviously, if you have 64 bit and 32 bit versions of that library, this
can no longer happen. If you have the right function from the library in
cache, but it's 32 bit and your application is 64 bit, then you still
need to fetch the same function from the 64 bit library.
I'm aware that I'm still grossly simplifying matters...
I also wrote:
> Intel's Itanium CPUs were not designed with 32 bit *performance* as a
> priority, and it shows. They *are* much slower when running 386 code.
and Tom replied:
> This is one of the reasons IA64 is almost dead.
One of many...
James.
--
E-mail address: james | Dalek invasion at work today. I plugged them into the
@westexe.demon.co.uk | net: they behave better than some Windows boxes. They
| make great spam filters: "Enlarge your..." "EX - TER -
| MI - NATE!" All in a day's work for a sysadmin...
