Lest one think that tweaking rmap is all that is happening in the memory
management world: a great deal of code is currently circulating which makes
big changes, and it has been finding its way into Linus's kernel.
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
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
- 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
- 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.
to post comments)