News for hackers. Stuff that matters.

A comment on Anatomy of a Program in Memory. Parent comment

Re:Anatomy of a Program in Memory by a-priori on Tuesday January 27, 2009 @11:13AM (#452292)
As narag says, it's only recently that this has become an issue. When physical memory size was orders of magnitude smaller than than the address space, it didn't matter that the kernel carved out 1GB of address space for itself. User applications still had the other 3GB, which was far more than any system had physical memory.

It's only during this limbo period when 4GB of RAM is relatively cheap, yet there are still 32-bit systems kicking around, that it becomes an issue. On a 64-bit system with a 16 exabyte address space, 1GB is a drop in the bucket. Once again, it won't matter.

(I suspect Linux allocates more than this for itself in 64-bit systems, but I don't know the details. At any rate, out of 16EB, even 100GB would hardly be noticed.)

[ Parent | on HN ]
Re:Anatomy of a Program in Memory by yan on Tuesday January 27, 2009 @11:25AM (#452314)
From the way I read those comments, I gathered that the comments implied that Windows "consumed" two gigs of ram, where as Linux took 1 gig. I thought there was a dissonance between how people understood "virtual memory," which is essentially a mapping function, to "memory," which people assume to be the physical ram.
[ Parent | on HN ]
Re:Anatomy of a Program in Memory by a-priori on Tuesday January 27, 2009 @02:56PM (#452614)
It's easy to make that mistake at first, but it is a very important distinction. Most of the time, for most processes, most of that space is unallocated. However, since it's basically impossible to change the size of the kernel area without relinking the process binaries, and since that area is shared between all processes, the size of that area has to remain fixed.

It is interesting that Linux and NT differ. Perhaps this is due to the fact that NT needs more kernel memory to house, e.g. the windowing system, whereas Linux systems put X in userspace? I'm speculating here.

Something I never considered: that design difference probably makes Wine's job easier, because between the 2GB and 3GB marks is a region of memory the Windows process assumes is inaccessible, yet in Linux is in userspace. They could (and probably do) load the Wine libraries here without interfering with the Windows process. It also means that it would be very difficult to implement Wine's complement, a way of running Linux binaries on Windows.

[ Parent | on HN ]
Re:Anatomy of a Program in Memory by kragen on Wednesday January 28, 2009 @02:03AM (#453454)
Linux used to be 2GiB/2GiB too, just like NT. It changed because people with big processes were unhappy; for a while there was an unofficial kernel patch for the 3GiB/1GiB split. Maybe NT didn't change because not as many people were running supercomputers on NT, or because changing NT is harder.

You don't have to relink your userland binaries to do this because they don't contain virtual addresses of kernel data structures, only their own data structures. Expanding the space available for mmap won't force those data structures to move.

You can pretty much load Wine libraries wherever you want; it's pretty rare for a program to break if memory it assumed was unmapped gets used for a library, and programs that break that way will have a lot of trouble when Windows versions change too. Generally programs are only linked with knowledge of where they themselves will be loaded in virtual memory. (Linux ELF shared libraries don't even know that.) All the other addresses are given to the program at startup. It is unusual for Linux binaries to believe that they will be loaded above 2GiB; the usual start address is 0x08048000.

Here's the memory map of a process running under Wine: http://gist.github.com/53853 --- note that there's a lot of Wine and X11 stuff loaded below 2GiB (0x80000000).

[ Parent | on HN ]
Re:Anatomy of a Program in Memory by brl on Tuesday January 27, 2009 @03:24PM (#452658)
It's pretty arbitrary really. It's rare to need more than 2 gigs of memory in a single user process. On the other hand, the more address space you have in the kernel the easier it is to use spare memory for IO buffer caching.
[ Parent | on HN ]
Re:Anatomy of a Program in Memory by narag on Tuesday January 27, 2009 @03:55PM (#452718)
From the way I read those comments, I gathered that the comments implied that Windows "consumed" two gigs of ram,

I'm afraid I didn't make myself clear before. I also think that commenters were wrong. I just tried to explain why. The article says that's the default arrangement, but if non-kernel memory grows bigger than 2 GB, I assume that it'll be allocated in the virtual space that's unused by kernel.

[ Parent | on HN ]