Slashdot Mirror

Does "the whole ecosystem" make up for the increased data cache misses and OOM kills that an existing device with 2 GB of RAM running software with 64-bit pointers would suffer compared to the same device running software with 32-bit pointers?

I need to offer you credit; you are right. The issue isn't really PAE, it's how the kernel manages memory on 32 bit x86 architectures with more than 1GB of memory installed. PAE simply exacerbates the problem. Here's an explanation of the complaint:

On ia_32 systems, the kernel splits memory into 3 zones; DMA, NORMAL, and HIGHMEM.

ZONE_DMA is the first 16MB of memory, and is generally avoided unless needed (due to lack of available higher memory, or for DMA mappings.) The kernel tries to reserve this address range for devices that use DMA mapping.

ZONE_NORMAL is an address space that is directly accessible to the kernel, and extends from 16MB to 896MB. Kernel data structures are stored in this space, including the kernel page tables. Memory mappings start to consume a lot of memory in ZONE_NORMAL, and thus PAE on ia_32 with a lot of installed memory can cause out of memory issues, even when there is a lot of available physical memory. User data can be allocated into ZONE_NORMAL, but is preferred to be placed in ZONE_HIGHMEM to free ZONE_NORMAL for kernel data structures.

ZONE_HIGHMEM is memory above the 896MB barrier. This address range is not directly accessible to the kernel. In order for the kernel to access anything in this zone, a temporary map must be made into ZONE_NORMAL. These mappings consume pages of ZONE_NORMAL, and suffer a performance hit. User space processes can access these pages directly (handled by the virtual memory manager system, of course.)

Generally, memory will be allocated to ZONE_HIGHMEM, ZONE_NORMAL, or finally ZONE_DMA in that order of preference.

The x86_64 architecture eliminates the need ZONE_HIGHMEM. ZONE_NORMAL extends all the way from 16MB to the end of physical memory. This approach simplifies memory management, improves performance, and is generally more flexible.

You're correct that there was a major issue with my original post... My memory of the kernel architecture had garbled HIGHMEM with PAE, and I was thinking that PAE required mapping pages above 4GB into lower memory. This would of course cause a huge performance penalty for any process consuming memory above 4GB. I deserve downmods for the technical inaccuracy.

Here's a very brief summary of the problems with HIGHMEM:
http://linux-mm.org/HighMemory

Here's a bunch of links used to refresh my memory:

http://www.makelinux.net/ldd3/chp-15-sect-1
https://www.kernel.org/doc/gorman/html/understand/understand005.html
http://unix.stackexchange.com/questions/5143/zone-normal-and-its-association-with-kernel-user-pages

However, many people insist on using more than 1GB of physical memory on such a 32 bit system. This makes it necessary for the Linux kernel to jump through some interesting hoops... Basically the system uses the following tactics: * Memory above the physical address of 896MB are temporarily mapped into kernel virtual memory whenever the kernel needs to access that memory. * Data which the kernel frequently needs to access is allocated in the lower 896MB of memory (ZONE_NORMAL) and can be immediately accessed by the kernel (see Temporary mapping). * Data which the kernel only needs to access occasionally, including page cache, process memory and page tables, are preferentially allocated from ZONE_HIGHMEM. * The system can have additional physical memory zones to deal with devices that can only perform DMA to a limited amount of physical memory, ZONE_DMA and ZONE_DMA32. * Allocations and pageout pressure on the various memory zones need to be balanced (see Memory Balancing).

Cortex A15 uses 40-bit physical addressing is really useless : it is x86 PAE

Kills random processes? As in kill -term? I've never seen that

It's the OOM Killer

Actually, they usually terminate the process that's using the most memory, or at least that has been my experience.

While that may tend to be the end result, Linux at least does try to be a bit intelligent about what the OOM Killer terminates.

No man, the OS is responsible for memory management. That's a major part of any OS, right up there with the scheduler. The memory management portion is responsible for allocating memory to an application and also for making sure that an application only accesses its own memory, or shared memory. So when an application tries to access a memory address you better believe that the OS is verifying that the application is allowed to do that. When an application tries to access memory that it doesn't own, that's one kind of general protection fault or page fault on Windows. The memory garbage collection routines definitely need to know which portions of memory are allocated to a certain process. Memory management is a major part of the Linux kernel. Here you go:

http://linux-mm.org/

I'm sorry... what? I don't see how that's a reasonable choice at all.

The 32-bit Linux kernel cannot efficiently handle more than 1 GB RAM. Linus Torvalds himself is outspoken on this subject and recommends using a 64-bit kernel with more than 1 GB (alas, I can't find the reference right now, but he has written many times on the subject in RealWorledTech.com's forums).

Here, I was real curious about this issue, so I looked it up:

http://linux-mm.org/HighMemory

Basically, when a system has more than 1GB of memory, the kernel can't directly map all physical RAM into its own address space (because 3GB of the virtual address space is reserved for applications...) - which makes certain operations more complex than they need to be. The kernel needs to take some extra steps when dealing with more than 1GB of physical RAM when exchanging memory addresses between different modules, for instance... The problem gets worse as you go beyond 4GB RAM and have to deal with PAE, etc...

You can get around that by changing the amount of virtual address space reserved for the kernel vs. user space - for instance a 2GB kernel/2GB user split of virtual address space on a system with 2GB RAM, or 3GB kernel/1GB user split on a system with 3GB RAM - but of course that's not ideal as it limits how much virtual memory (RAM + swap, etc.) is available to user processes...

On the other hand, using 64-bit in userspace is pointless for most users. Most applications don't need more than 3GB of RAM. Also, there are binary plugins, etc, which only work in 32-bit.

I don't know that I agree with that. Among other things, in x86-64 there are twice as many general-purpose registers. This makes it a lot easier for GCC to optimize compiled code effectively. Additionally the other features present on modern processes can be safely taken as assumptions by the compiler and standard libraries. The binary-only problem isn't as bad as it used to be, either - video drivers are available in 64-bit, flash is available in 64-bit, Java is available in 64-bit... I just recently built a new system and I decided to go fully 64-bit - I think it's worth it, and so far there's been only minimal difficulty. I guess the main disadvantage of a 64-bit userspace is the increased size of pointers and std::size_t, etc. using more RAM. To me the tradeoff would be worth it.

64-bit kernel and 32-bit userspace is the most efficient and practical choice for the vast majority of users.

I've set up suspend-to-file before, since my laptop has 8GB of RAM and taking a >8GB chunk out of even a 250GB disc is no small feat - as long as your kernel has support for your filesystem of choice built in, you just run a tool to find the address of the file in question (think it's just a mater of setting your file in the suspend config and then looking in /sys for the address). This way, if I desperately need an extra 8GB of space, I can just `rm /swapfile`, instead of going through the palaver of resizing swap and the surrounding partitions. For the record, I keep a 512MB swap file of which I've never seen more than 15MB used. Anyone's who's ever done anything like accidentally rsync 8 billion files [thank god for rsync 3] will know that having gads of swap available is a curse, since disc speeds haven't kept parity with RAM - the system will become almost totally unusable until it hits the memory limit and oom-killer has its way. In such an event, you *want* to run out of swap as soon as possible.

I thought the idea of using an 8GB swap file ridiculous, since my apps rarely use more than 2GB physical for their working data set - but they do lots of random lookups on data so the huge file caches are a massive bonus to me.

What I can't understand is why suspend doesn't seem to flush the file caches from memory when hibernating - writing 8GB of memory to swap, even when using compression, takes an utter age.

Edit: just found this, added in 2.6.16. Will give this a whirl and see if it improves hibernate any... http://linux-mm.org/Drop_Caches

Recently I had also getting tired of my computing projects that taught me nothing other than blindly following assignment requirements. The marking scheme makes students only try to make a program works and throw the program away after project submission. It would be great if universities can assign students to improve some open source projects too. Anyway the only difference I found in computing assignments from essay assignments is that almost no one had even attempt to copy code from any open source project just because either they are too lazy to read code or the assignment is too easy.

However I can foresee that if this kind of assignment becomes popular the assignment might become too hard for students. Because Wikipedia is open, a student not only needs to compete with other students in the same university, but also students from other universities and any other people around the world. The quality of Wikipedia will also be improved until so good that its very hard to make any major edit without significant knowledge. Wikipedia may haven't reach this stage, but it will.

Hence I can think of 2 ways to make it an easier assignment: one is to edit some other wiki such as LinuxMM. Or the university may start its own Wiki/Open Source project to reduct competition from the outside world. Of course the latter idea is not that good compared with the original idea, but when we reach some stage this might be the alternative way that is at least better than current system.

Well, I don't know about Windows, but on Linux, an application can't deal gracefully with running out of memory unless /proc/sys/vm/overcommit_memory is set to 2.

It also had a few factual errors, for example ext2 and ext3 are not extent based at all, they are classical block based filesystems.

Also, most of the Linux page fault code is architecture independant. As it happens, I just wrote an article explaining Linux page fault handling for the Linux-MM wiki. You can find some details there...

• Compaq Proliant DL590
• Linux MM homepage Look at the 64Gb entry from 1999

I do use Linux/Intel in a budget conscious organization, and so far the xSeries servers from IBM have behaved like a charm. I've never deployed SUNs.