SuSE and Siemens Release Linux Memory Extension
hussar noted that SuSE and Siemens have developed a memory extension that will allow Linux to use up to 4GB of memory. Linus has reportedly approved its inclusion in kernel 2.3.15. The strangest part is excite has taken to posting about Linux Kernel Patches. Pretty crazy stuff.
My best example of this was when I saw a rehash of Pravenich's 2.4 kernel thing on a tech news site - they'd duplicated his mistakes, and were brainwashing the masses with the stuff! ;)
A big company does something, they send out a press release. Nothing new there, it is just that it is about Linux.
Now, that someone has come up with a bigmem patch that Linus will live with, THAT is news!
This is a big deal for some users. A real shocker will be if someone comes up with a patch to use the 36 bit addressing on the P6 cpu, for up to 64GB ram on Intel machines.
Plato seems wrong to me today
I'm not sure, given that the "enterprise" edition lets it use only 1GB, but note that this is virtual memory, not physical memory - this doesn't mean NT is consuming 2GB of physical memory.
I infer from the stuff I've seen in the "Inside Windows NT" books that it has a common page/buffer cache; the first edition of Inside Windows NT says
which is similar to what some UNIX systems (e.g., SunOS 4.x, SVR4-based systems, FreeBSD, etc.) do; I have the impression that if the Linux kernel doesn't yet have a unified page/buffer cache in a stable kernel, it's going into the 2.3[.x] line.
Most of memory is, in effect, a page cache on these systems, unless you count only pages not currently being used as cached, in which case most of memory not used by pages currently being used is a page cache. In addition, the buffer cache (in the sense of the cache of pages read in from files) is just part of the page cache.
I find it somewhat telling that the article didn't mention Andrea Arcangeli and Gerhard Wichert, workin at SuSe and Siemens respectively and wrote this patch pretty much dual-handedly. I suppose with the corpratization of linux, the companies are more important now than the actual people who make linux what it is. At the very least, a link to Andrea's archived message on l-k would give credit where it is due.
This is great work. Just think what will happen when the SGI big memory project is ready. Check out http://oss.sgi.com/projects/bigmem/. Wow. Two big memory solutions. I just don't know which to choose. Oh. Hang on. I don't have four *fricking* gigabytes of RAM....
- The hardware vendor gets to show off their hardware.
- The hardware vendors gains some purely positive publicity and goodwill from the community
- Everyone else benefits from the contribution.
Plus, a significant contribution can be merely the seed for further developments, since anyone in the world can read the patch and contribute their own. It's a win-win situation all around.True, in the sense that at any given instant of time, the linear address space of a process can be no larger than 4GB (and, as segmented addresses get translated to 32-bit linear addresses before being run through the page table, segmentation doesn't help).
However, as I noted in another post, a process could, if the OS lets it (and most OSes you'd run on big machines do, these days), map stuff into and out of its address space, and more than one process could exist on the machine, so you can use it for userland code, userland data, kernel code, kernel data, mapped files, buffer cache, whatever, just as you can use the first 4GB - it's just a question of what the OS does or lets applications do.
Just a quick note to everybody. It is not about being able to use 4GB of physical memory. It is to enable process to use more than 2GB of memory. Traditional Linux memory model to is split the lower half for kernel memory and upper half for user memory. To check if the pointer is pointing to a kernel memory you just need to check its MSB.
test %eax,0x8000000
je user_mem_label
I think they have worked on 3GB prior to this. SOrry, been a while since I checked the kernel lists.
Anyhow, this is only of practical use to database developers. maybe some but not many. In any case, you might as well use a 64-bit architecture.
Hasdi
5) Office 2000 memory requirements now supported by Linux, making port much easier.
4) Enhances sales potential of Windows 2000 -- WINE now able to run W2K under Linux.
3) Yet another fun Linux feature to deny and obfuscate.
2) Can complain before tech-unclued journalists about Linux's memory requirements -- 4G compared to W2K's 128M.
1) Now that Linux supports 4G of RAM, it will be competition on the everyday Joe's desktop, thus making MS-DOJ trial irrelevant.
(Darn Excite, slashdotted again.)
We want endless gardens of data, where the bits can flower, flourish and reproduce. -- Andy Mueller-Maguhn
You are confusing the virtual and physical address spaces.
The Intel P6 line has a 36bit physical address bus allowing the chip to address up to 64GB of physical memory. However, since it is a 32-bit processor, you can only see 4GB of this memory at any time. You can change what you can see by playing games with PTEs (page table entries), and/or segment registers.
To address >4GB of memory requires use of either wide (64-bit) PTEs, or the strange mode Intel added to the PII, that allows large pages with narrow PTEs.
The Sequent Dynix/ptx OS supports up to 64GB of physical memory. The hard part is conserving enough kernel virtual address space.