1. Short overview (for news sites, etc)

2. Important things (AKA: the cool stuff)

2.1. RCU Preempt support

Recommended LWN article: [http://lwn.net/Articles/253651/ "The design of preemptible read-copy-update"]

[http://en.wikipedia.org/wiki/Read-copy-update RCU] is a very powerful locking scheme used in Linux to scale to [http://lkml.org/lkml/2007/5/4/314 very large] number of CPUs on a single system. However, it wasn't well suited for the Real Time patchsets that have been developed to make Linux a RT OS, because some parts weren't preemptible, causing latencies too big for RT workloads. In 2.6.25, RCU can be preempted, eliminating that source of latencies and making Linux a bit more RT-ish.

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e260be673a15b6125068270e0216a3bfbfc12f87 (commit)]

2.2. FIFO ticket spinlocks

Recommended article: [http://lwn.net/Articles/267968/ "Ticket spinlocks"]

In certain workloads, spinlocks can be unfair, ie: a process spinning on a spinlock can be starved up to 1,000,000 times. Usually starvation in spinlocks is not a problem, because it becomes a performance problem before any starvation is noticed, but testing has showed the contrary. And it's always possible to find an obscure corner case that will generate a lot of contention on some lock, and the processor that will grab the lock does it randomly. With the new spinlocks, the processes grab the spinlock in FIFO order. Spinlocks configured to run in more than 255 CPUs will also use a 32-bit value (instead of the 16 bits used when NR_CPUS < 255) that allows a theoretical limit of up to 65536 processors.

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=314cdbefd1fd0a7acf3780e9628465b77ea6a836 (commit)]

2.3. Better process memory usage measurement

Recommended LWN article: [http://lwn.net/Articles/230975/ "How much memory are applications really using?"]

Measuring how much memory processes are using is more difficult than it looks, specially when processes are sharing the memory used. Features like /proc/$PID/smaps (added in [http://kernelnewbies.org/Linux_2_6_14 2.6.14]) help, but it has not been enough. 2.6.25 adds new statistics to make this task easier. A new /proc/$PID/pagemaps file is added for each process. In this file the kernel exports (in binary format) the physical page localization for each page used by the process. Comparing this file with the files of other processes allows to know what pages they are sharing. Another file, /proc/kpagemaps, exposes another kind of statistics about the pages of the system. The author of the patch, Matt Mackall, proposes two new statistic metrics: "proportional set size" (PSS) - divide each shared page by the number of processes sharing it; and "unique set size" (USS) (counting of pages not shared). The first statistic, PSS, has also been added to each file in /proc/$PID/smaps. In [http://selenic.com/repo/pagemap/ this HG repository] you can find some sample command line and graphic tools that exploits all those statistics.

Code: (commit [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1e88328111aae3ea408f346763ba9f9bad71f876 1], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=304daa8132a95e998b6716d4b7bd8bd76aa152b2 2], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=161f47bf41c5ece90ac53cbb6a4cb9bf74ce0ef6 3], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=85863e475e59afb027b0113290e3796ee6020b7d 4])

2.4. Memory Resource Controller

Recommended LWN article: [http://lwn.net/Articles/243795/ "Controlling memory use in containers"]

The memory resource controller is a cgroups-based feature. Cgroups, aka "Control Groups", is a feature that was merged in [http://kernelnewbies.org/Linux_2_6_24 2.6.24], and its purpose is to be a generic framework where several "resource controllers" can plug in and manage different resources of the system such as process scheduling or memory allocation. It also offers a unified user interface, based on a virtual filesystem where administrators can assign arbitrary resource constraints to a group of chosen tasks. For example, in [http://kernelnewbies.org/Linux_2_6_24 2.6.24] they merged two resource controllers: Cpusets and Group Scheduling. The first allows to bind CPU and Memory nodes to the arbitrarily chosen group of tasks, aka cgroup, and the second allows to bind a CPU bandwidth policy to the cgroup.

The memory resource controller isolates the memory behavior of a group of tasks -cgroup- from the rest of the system. It can be used to:

Isolate an application or a group of applications. Memory hungry applications can be isolated and limited to a smaller amount of memory.
Create a cgroup with limited amount of memory, this can be used as a good alternative to booting with mem=XXXX.
Virtualization solutions can control the amount of memory they want to assign to a virtual machine instance.
A CD/DVD burner could control the amount of memory used by the rest of the system to ensure that burning does not fail due to lack of available memory.

The configuration interface, like all the cgroups, is done by mounting the cgroup filesystem with the "-o memory" option, creating a randomly-named directory (the cgroup), adding tasks to the cgroup by catting its PID to the 'task' file inside the cgroup directory, and writing values to the following files: 'memory.limit_in_bytes', 'memory.usage_in_bytes' (memory statistic for the cgroup), 'memory.stats' (more statistics: RSS, caches, inactive/active pages), 'memory.failcnt' (number of times that the cgroup exceeded the limit), and 'mem_control_type'. OOM conditions are also handled in a per-cgroup manner: when the tasks in the cgroup surpass the limits, OOM will be called to kill a task between all the tasks involved in that specific cgroup.

2.5. EXT4 update

Recommended article: [http://lwn.net/Articles/266274/ "A better ext4"]

EXT4 mainline snapshot gets an update with a bunch of features: Multi-block allocation, large blocksize up to PAGEZIZE (Shouldn't this be "PAGESIZE"? -zamb), journal checksumming, large file support, large filesystem support, inode versioning, and allow in-inode extended attributes on the root inode. These features should be the last ones that require on-disk format changes. Other features that don't affect the disk format, like delayed allocation, have still to be merged.

2.6. MN10300/AM33 architecture support

The MN10300/AM33 architecture is now supported under the "mn10300" subdirectory. 2.6.25 adds support MN10300/AM33 CPUs produced by MEI. It also adds board support for the ASB2303 with the ASB2308 daughter board, and the ASB2305. The only processor supported is the MN103E010, which is an AM33v2 core plus on-chip devices. Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b920de1b77b72ca9432ac3f97edb26541e65e5dd (commit)]