2.5.32-mm2

Andrew Morton (akpm@zip.com.au)
Thu, 29 Aug 2002 01:36:46 -0700


URL: http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.32/2.5.32-mm2/

- Linus has merged per-zone-lru and per-zone-lock, so the NUMA guys should
be less than totally grumpy for several milliseconds.

- Linus has merged tlb-speedup. There are new stats in /proc/meminfo
which boast about how many global tlb invalidations have been saved.
These will disappear soon.

- The hashed rmap spinlocking patch has been shown to slow down the big
NUMA machines, and was of marginal benefit for SMP, and it added complexity.
It has been shuffled to apply after rmap-speedup and the highpte patch.
So it has basically been dropped. Daniel is cooking up something else.

+ A BUG_ON(page_count(page)) has been added to put_page_testzero()
(per Daniel's suggestion). Should catch the possible double-free
of LRU pages.

+ pagevec_lru_del() is removed

+ a change to the refill_inactive logic suggested by Ed Tomlinson

+ Janet Morgan's patch which speeds up readv&writev for O_DIRECT is
included. It needs some interface changes yet - generic_file_read
and generic_file_write should be changed to take an iovec, which will
allow lots of code to be removed.

+ Ed Tomlinson's slablru patch is now included. This puts slab pages
onto the LRU in an attempt to balance the various caches against
other demands on the page allocator. Seems to work nicely from a
quick test. It is early days for this code.

I added a field to /proc/meminfo which displays the total amount of
slab memory.

+ pte_highmem is still included, but it has mysteriously broken itself.
Don't enable this in config.

pte_highmem touches all architectures in possibly injurious ways. It
would be helpful if it received some non-x86 testing, please. Just the
"does it compile and boot" test.

2.5.32-mm2 hasn't had a ton of stability testing....

linus.patch
Incremental BK patch from Linus' tree

scsi_hack.patch
Fix block-highmem for scsi

misc.patch
misc stuff

ext3-htree.patch
Indexed directories for ext3

put_page-test.patch
Check for zero-ref pages in put_page_testzero()

pagevec_lru_del.patch
Remove pagevec_lru_del()

put_page_cleanup.patch
Clean up put_page() and page_cache_release().

anon-batch-free.patch
Batched freeing and de-LRUing of anonymous pages

writeback-sync.patch
Writeback fixes and tuneups

ext3-inode-allocation.patch
Fix an ext3 deadlock

ext3-o_direct.patch
O_DIRECT support for ext3.

discontig-paddr_to_pfn.patch
Convert page pointers into pfns for i386 NUMA

discontig-setup_arch.patch
Rework setup_arch() for i386 NUMA

discontig-mem_init.patch
Restructure mem_init for i386 NUMA

discontig-i386-numa.patch
discontigmem support for i386 NUMA

cleanup-mem_map-1.patch
Clean up lots of open-coded uese of mem_map[]. For ia32 NUMA

zone-pages-reporting.patch
Fix the boot-time reporting of each zone's available pages

enospc-recovery-fix.patch
Fix the __block_write_full_page() error path.

fix-faults.patch
Back out the initial work for atomic copy_*_user()

spin-lock-check.patch
spinlock/rwlock checking infrastructure

refill-rate.patch
refill the inactive list more quickly

copy_user_atomic.patch

kmap_atomic_reads.patch
Use kmap_atomic() for generic_file_read()

kmap_atomic_writes.patch
Use kmap_atomic() for generic_file_write()

throttling-fix.patch
Fix throttling of heavy write()rs.

dirty-state-accounting.patch
Make the global dirty memory accounting more accurate

rd-cleanup.patch
Cleanup and fix the ramdisk driver (doesn't work right yet)

discontig-cleanup-1.patch
i386 discontigmem coding cleanups

discontig-cleanup-2.patch
i386 discontigmem cleanups

writeback-thresholds.patch
Downward adjustments to the default dirtymemory thresholds

buffer-strip.patch
Limit the consumption of ZONE_NORMAL by buffer_heads

rmap-speedup.patch
rmap pte_chain space and CPU reductions

wli-highpte.patch
Resurrect CONFIG_HIGHPTE - ia32 pagetables in highmem

readv-writev.patch
O_DIRECT support for readv/writev

slablru.patch
age slab pages on the LRU
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/