The VM seems now solid and effient but still it will be interesting to hear details about any prossible regression or instability (also Linus has ideas on things to change in such area). I probably won't release any further -aa patchkit until 25 Sep but I'll try to be responsive for anything very urgent. (I'll queue all low prio emails for next week) Only in 2.4.10pre12aa1: 00_compile-sysrq-1 Only in 2.4.10pre12aa1: 00_shrink_cache-BUG-1 Only in 2.4.10pre12aa1: 00_swap-writepage-1 Only in 2.4.10pre12aa1: 00_swapin-wrprotect-1 Only in 2.4.10pre12aa1: 00_swapout-1 Only in 2.4.10pre12aa1: 00_vm-writepage-reference-1 Merged in mainline. Only in 2.4.10pre12aa1: 00_GFP_ATOMIC-1 Only in 2.4.10pre13aa1: 00_GFP_ATOMIC-2 The important part of it merged in mainline, left only the lowering of the ATOMIC low watermark (to increase the ATOMIC GAP). Only in 2.4.10pre13aa1: 00_debug-gfp-1 Replaced the __builtin_return_address(0) in GFP with a show_stack if CONFIG_DEBUG_GFP is defined. (the caller was going to be in the mm so __builtin_return_address(0) was useless). Only in 2.4.10pre12aa1: 00_flush-inode-reschedule-1 Only in 2.4.10pre13aa1: 00_flush-inode-reschedule-2 Include compiler.h. Only in 2.4.10pre12aa1: 00_highmem-debug-2 Rediffed. Only in 2.4.10pre12aa1: 00_ramdisk-secure-1 Only in 2.4.10pre12aa1: 00_ramdisk-secure-1-const-1 Only in 2.4.10pre13aa1: 00_ramdisk-secure-2 Fixed ramdisk-secure, now it has its own address space operations. When used as a blkdev it now with works like ramfs internally. In turn initrd works again. Only in 2.4.10pre13aa1: 00_reiserfs-IO-1 Mark the buffer referenced when making it visible to the VM so it's more likley that it won't be collected away before we have a chance to allocate it (getblk/grow_buffers interaction should be fixed but this is a simple one liner for now). Only in 2.4.10pre12aa1: 00_rwsem-fair-20-recursive-1 Only in 2.4.10pre13aa1: 00_rwsem-fair-20-recursive-2 Rediffed (only needed for core dumping now). Only in 2.4.10pre13aa1: 00_start-aggressive-readahead-1 XFS needs to know when it can do possibly wasteful aggressive readhaead (it doesn't want to shrink caches to make space for the possibly wasteful readahead). This new VM call will provide this information. Other fs are free to use it too of course. Only in 2.4.10pre13aa1: 00_unmap-dirty-pte-1 I grepped over the whole 600 pages of the latest x86 system developer manual and I couldn't find the proof that I'm wrong. We can have pagecache pages with pte writeable and non dirty at some point. Now what happens if the userspace task in the other cpu touches the writeable page between our "ptep_get_and_clear" and the "flush_tlb_page"? Is the resulting pte still zero and the task get into a page fault? Or as I am worried it could also just end with the pte with only the dirty bit set? Does somebody know for sure? I can imagine the cpu finding the tlb state writeable, and issuing just a locked bit test and set in the pte without caring to check if the pte is zero or not. If the cpu just set the bit this patch will avoid to lose a shared mapping update. Otherwise it's a safe noop so I keep it applied until this issue is sorted out. Only in 2.4.10pre13aa1: 00_vmalloc-cache-flush-1 Reintroduced the cache flush in vmalloc, (not the tlb flush) per DaveM request. Noop for x86/alpha. Only in 2.4.10pre13aa1: 10_highmem-debug-3 Rediffed. Only in 2.4.10pre13aa1: 10_numa-sched-10 Only in 2.4.10pre12aa1: 10_numa-sched-9 Rediffed, now it compiles :). Only in 2.4.10pre12aa1: 50_uml-patch-2.4.9-6.bz2 Only in 2.4.10pre13aa1: 50_uml-patch-2.4.9-7-1.bz2 Picked last uml update from sourceforge. Only in 2.4.10pre12aa1: 53_uml-gcc-3.0-1 Merged in mainline -7 revision. Only in 2.4.10pre13aa1: 57_ptrace_disable-1 Only in 2.4.10pre13aa1: 58_uml-tlb-1 Allow uml compilation, tlb.h copied from 2.4.9ac12. Only in 2.4.10pre12aa1: 60_atomic-alloc-5 Only in 2.4.10pre13aa1: 60_atomic-alloc-6 Rediffed (now USEDFPU is defined only once :). Only in 2.4.10pre12aa1: 60_tux-2.4.9-ac10-J4 Only in 2.4.10pre13aa1: 60_tux-2.4.9-ac10-J9 Picked last update from www.redhat.com/~mingo/ .