From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: [PATCH 00/20] mm: Preemptibility -v5 Date: Mon, 18 Oct 2010 13:24:33 +0200 Message-ID: <20101018112433.556591568@chello.nl> Return-path: Sender: linux-kernel-owner@vger.kernel.org To: Andrea Arcangeli , Avi Kivity , Thomas Gleixner , Rik van Riel , Ingo Molnar , akpm@linux-fou Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Benjamin Herrenschmidt , David Miller , Hugh Dickins , Mel Gorman , Nick Piggin , Peter Zijlstra , Paul McKenney , Yanmin Zhang , Stephen Rothwell List-Id: linux-arch.vger.kernel.org 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 preemptible. 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 it 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 Linus' tree as of about an hour ago): git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git mmu_preempt DaveM mentioned some sparc64 trouble with the -v4 posting, this turned out to be a false positive as unpatched kernels also are having trouble on his machines. Linus, Andrew, Stephen, can we add this to -next for .37? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from canuck.infradead.org ([134.117.69.58]:60278 "EHLO canuck.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755261Ab0JRLfp (ORCPT ); Mon, 18 Oct 2010 07:35:45 -0400 Message-ID: <20101018112433.556591568@chello.nl> Date: Mon, 18 Oct 2010 13:24:33 +0200 From: Peter Zijlstra Subject: [PATCH 00/20] mm: Preemptibility -v5 Sender: linux-arch-owner@vger.kernel.org List-ID: To: Andrea Arcangeli , Avi Kivity , Thomas Gleixner , Rik van Riel , Ingo Molnar , akpm@linux-foundation.org, Linus Torvalds Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Benjamin Herrenschmidt , David Miller , Hugh Dickins , Mel Gorman , Nick Piggin , Peter Zijlstra , Paul McKenney , Yanmin Zhang , Stephen Rothwell Message-ID: <20101018112433.3BqUYCAjWsfmWEQYgEwACZthuk_c0aPLWud5HvaRP3E@z> 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 preemptible. 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 it 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 Linus' tree as of about an hour ago): git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git mmu_preempt DaveM mentioned some sparc64 trouble with the -v4 posting, this turned out to be a false positive as unpatched kernels also are having trouble on his machines. Linus, Andrew, Stephen, can we add this to -next for .37?