Other memory management work

For example, 2.5.34 includes Patricia Gaughen's discontiguous memory patch, which is aimed at the needs of large, NUMA systems. On such systems, you no longer just have a simple array of memory; instead, the system's RAM is broken up into zones, each of which is attached to a particular NUMA node. Memory accesses within a node are faster than cross-node references, so the kernel needs to know where any given page resides. Memory on these systems can also have address holes between each node's zone.

The discontiguous memory patch does away with the classic mem_map array, which contained one struct page structure for each page on the system. The memory map is now split into separate, per-node maps, and all references to mem_map in the kernel have been changed. Rather than dealing with simple indexes into mem_map, the kernel now works with page frame numbers; an old reference to mem_map+i is now pfn_to_page(i). For the most part, code which did not access mem_map directly will likely require no changes in response to the discontiguous memory patches. But there will be exceptions...

Andrew Morton's "-mm" patches have become the staging area for memory management changes. The current patch as of this writing (2.5.34-mm1) contains a long list of other changes, including:

• Directory indexes for the ext3 filesystem (by Daniel Phillips). Calling this one "memory management" is a bit of a stretch, of course, but it is a definite performance improver when large directories are used.

• A patch by William Lee Irwin which lets the i386 architecture maintain page tables in high memory.

• A change to the readv and writev system calls (by Janet Morgan) which submits all segments for I/O in parallel; this patch greatly speeds up direct disk I/O operations.

• Rohit Seth's large page patch for the i386 architecture (covered here last month).

• A patch which allows copy_from_user and copy_to_user to be called in atomic (non-blocking) situations. If the copy operation encounters a page fault, it simply fails.

• ..and many other changes.

One interesting side result from work like the atomic copy_*_user functions and the preemptible kernel is a formalization of just when the kernel is performing an atomic operation. Code in the 2.4 (and prior) kernel could check for certain situations where atomic operation was required, such as when servicing an interrupt. In 2.5, other atomic situations (i.e. holding a spinlock) are tracked, and it is easy for code with a need to say "don't interrupt me or sleep now." The result should be more explicit code and fewer bugs.