From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751563AbcDTXz7 (ORCPT ); Wed, 20 Apr 2016 19:55:59 -0400 Received: from ozlabs.org ([103.22.144.67]:51243 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751240AbcDTXz6 (ORCPT ); Wed, 20 Apr 2016 19:55:58 -0400 Date: Thu, 21 Apr 2016 09:55:55 +1000 From: Stephen Rothwell To: Hugh Dickins Cc: Andrew Morton , "Kirill A. Shutemov" , Andrea Arcangeli , Andres Lagar-Cavilla , Yang Shi , Ning Qu , kernel test robot , Xiong Zhou , Matthew Wilcox , Greg Thelen , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH mmotm 4/5] huge tmpfs: avoid premature exposure of new pagetable revert Message-ID: <20160421095555.6c896fa4@canb.auug.org.au> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Hugh, On Sat, 16 Apr 2016 16:38:15 -0700 (PDT) Hugh Dickins wrote: > > This patch reverts all of my 09/31, your > huge-tmpfs-avoid-premature-exposure-of-new-pagetable.patch > and also the mm/memory.c changes from the patch after it, > huge-tmpfs-map-shmem-by-huge-page-pmd-or-by-page-team-ptes.patch > > I've diffed this against the top of the tree, but it may be better to > throw this and huge-tmpfs-avoid-premature-exposure-of-new-pagetable.patch > away, and just delete the mm/memory.c part of the patch after it. > > This is in preparation for 5/5, which replaces what was done here. > Why? Numerous reasons. Kirill was concerned that my movement of > map_pages from before to after fault would show performance regression. > Robot reported vm-scalability.throughput -5.5% regression, bisected to > the avoid premature exposure patch. Andrew was concerned about bloat > in mm/memory.o. Google had seen (on an earlier kernel) an OOM deadlock > from pagetable allocations being done while holding pagecache pagelock. > > I thought I could deal with those later on, but the clincher came from > Xiong Zhou's report that it had broken binary execution from DAX mount. > Silly little oversight, but not as easily fixed as first appears, because > DAX now uses the i_mmap_rwsem to guard an extent from truncation: which > would be open to deadlock if pagetable allocation goes down to reclaim > (both are using only the read lock, but in danger of an rwr sandwich). > > I've considered various alternative approaches, and what can be done > to get both DAX and huge tmpfs working again quickly. Eventually > arrived at the obvious: shmem should use the new pmd_fault(). > > Reported-by: kernel test robot > Reported-by: Xiong Zhou > Signed-off-by: Hugh Dickins > --- > mm/filemap.c | 10 -- > mm/memory.c | 225 +++++++++++++++++++++---------------------------- > 2 files changed, 101 insertions(+), 134 deletions(-) I added this at the end of mmotm in linux-next today. I will leave Andrew to sort it out later. -- Cheers, Stephen Rothwell