Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932627AbbLSFX4 (ORCPT ); Sat, 19 Dec 2015 00:23:56 -0500 Received: from mga03.intel.com ([134.134.136.65]:25988 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751140AbbLSFXw (ORCPT ); Sat, 19 Dec 2015 00:23:52 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,448,1444719600"; d="scan'208";a="874753180" Date: Fri, 18 Dec 2015 22:23:49 -0700 From: Ross Zwisler To: Jan Kara Cc: Ross Zwisler , linux-kernel@vger.kernel.org, "H. Peter Anvin" , "J. Bruce Fields" , "Theodore Ts'o" , Alexander Viro , Andreas Dilger , Dave Chinner , Ingo Molnar , Jan Kara , Jeff Layton , Matthew Wilcox , Thomas Gleixner , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@ml01.01.org, x86@kernel.org, xfs@oss.sgi.com, Andrew Morton , Dan Williams , Matthew Wilcox , Dave Hansen Subject: Re: [PATCH v3 2/7] dax: support dirty DAX entries in radix tree Message-ID: <20151219052349.GA3553@linux.intel.com> Mail-Followup-To: Ross Zwisler , Jan Kara , linux-kernel@vger.kernel.org, "H. Peter Anvin" , "J. Bruce Fields" , Theodore Ts'o , Alexander Viro , Andreas Dilger , Dave Chinner , Ingo Molnar , Jan Kara , Jeff Layton , Matthew Wilcox , Thomas Gleixner , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org, x86@kernel.org, xfs@oss.sgi.com, Andrew Morton , Dan Williams , Matthew Wilcox , Dave Hansen References: <1449602325-20572-1-git-send-email-ross.zwisler@linux.intel.com> <1449602325-20572-3-git-send-email-ross.zwisler@linux.intel.com> <20151218090110.GB4297@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151218090110.GB4297@quack.suse.cz> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2242 Lines: 42 On Fri, Dec 18, 2015 at 10:01:10AM +0100, Jan Kara wrote: > On Tue 08-12-15 12:18:40, Ross Zwisler wrote: > > Add support for tracking dirty DAX entries in the struct address_space > > radix tree. This tree is already used for dirty page writeback, and it > > already supports the use of exceptional (non struct page*) entries. > > > > In order to properly track dirty DAX pages we will insert new exceptional > > entries into the radix tree that represent dirty DAX PTE or PMD pages. > > These exceptional entries will also contain the writeback addresses for the > > PTE or PMD faults that we can use at fsync/msync time. > > > > There are currently two types of exceptional entries (shmem and shadow) > > that can be placed into the radix tree, and this adds a third. There > > shouldn't be any collisions between these various exceptional entries > > because only one type of exceptional entry should be able to be found in a > > radix tree at a time depending on how it is being used. > > I was thinking about this and I'm not sure the use of exceptional entries > cannot collide. DAX uses page cache for read mapping of holes. When memory > pressure happens, page can get evicted again and entry in the radix tree > will get replaced with a shadow entry. So shadow entries *can* exist in DAX > mappings. Thus at least your change to clear_exceptional_entry() looks > wrong to me. > > Also when we'd like to insert DAX radix tree entry, we have to count with > the fact that there can be shadow entry in place and we have to tear it > down properly. You are right, thank you for catching this. I think the correct thing to do is to just explicitly disallow having shadow entries in trees for DAX mappings. As you say the only usage is to track zero page mappings for reading holes which will get minimal benefit from shadow entries, and this choice makes the logic both in clear_exceptional_entry() and in the rest of the DAX code simpler. I've sent out a v5 that fixes this issue. -- 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/