[PATCH 00/25] mm: Preemptibility -v7

From: Peter Zijlstra
Date: Tue Jan 25 2011 - 13:03:28 EST

This patch-set makes part of the mm a lot more preemptible. It converts
i_mmap_lock and anon_vma->lock to mutexes and makes mmu_gather fully

The main motivation was making mm_take_all_locks() preemptible, since it
appears people are nesting hundreds of spinlocks there.

The side-effects are that can finally make mmu_gather preemptible,
something which lots of people have wanted to do for a long time.

It also gets us anon_vma refcounting, which seems to result in a nice
cleanup of the anon_vma lifetime rules wrt KSM and compaction.

This patch-set is build and boot-tested on x86_64 (a previous version was
also tested on Dave's Niagra2 machines, and I suppose s390 was too when
Martin provided the conversion patch for his arch).

There are no known architectures left unconverted.

Yanmin ran the -v3 posting through the comprehensive Intel test farm
and didn't find any regressions.

( Not included in this posting are the 4 Sparc64 patches that implement
gup_fast, those can be applied separately after this series gets
anywhere. )

The full series (including the Sparc64 gup_fast bits) also available in -git
form from (against something post .38-rc2):


Changes since -v6:

Suggested by Hugh:
- reordered the patches
- changed to GFP_NOWAIT | __GFP_NOWARN to allocate mmu_gather pages
- s/lock/mutex/ for the spinlock to mutex conversion
- removed all DEFINE_PER_CPU(struct mmu_gather, mmu_gather) remnants
- split the i_mmap_lock and anon_vma->lock conversion
- removed some KSM wrappers
- avoid tlb_flush_mmu() while holding pte_lock

- remove the i_mmap_lock lockbreak in truncate (XXX)
- arch/tile __pte_free_tlb() change

- decide if we want to actually remove the i_mmap_lock lockbreak
- figure out if LOCK vs MB works or add a smp_mb() to patch #23
- figure out what to do with sparc's tlb_batch lack of ->fullmm

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