From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: [PATCH v7 06/22] Replace XIP read and write with DAX I/O Date: Sun, 13 Apr 2014 14:05:52 -0400 Message-ID: <20140413180552.GS5727@linux.intel.com> References: <3ebe329d8713f7db4c105021a845316a47a29797.1395591795.git.matthew.r.wilcox@intel.com> <20140408175600.GE2713@quack.suse.cz> <20140408202102.GB5727@linux.intel.com> <20140409091450.GA32103@quack.suse.cz> <20140409151908.GD5727@linux.intel.com> <20140409205529.GO32103@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Matthew Wilcox , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org To: Jan Kara Return-path: Content-Disposition: inline In-Reply-To: <20140409205529.GO32103@quack.suse.cz> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Apr 09, 2014 at 10:55:29PM +0200, Jan Kara wrote: > > In addition to writing back dirty pages, filemap_write_and_wait_range() > > will evict clean pages. Unintuitive, I know, but it matches what the > > direct I/O path does. Plus, if we fall back to buffered I/O for holes > > (see above), then this will do the right thing at that time. > Ugh, I'm pretty certain filemap_write_and_wait_range() doesn't evict > anything ;). Direct IO path calls that function so that direct IO read > after buffered write returns the written data. In that case we don't evict > anything from page cache because direct IO read doesn't invalidate any > information we have cached. Only direct IO write does that and for that we > call invalidate_inode_pages2_range() after writing the pages. So I maintain > that what you do doesn't make sense to me. You might need to do some > invalidation of hole pages. But note that generic_file_direct_write() does > that for you and even though that isn't serialized in any way with page > faults which can instantiate the hole pages again, things should work out > fine for you since that function also invalidates the range again after > ->direct_IO callback is done. So AFAICT you don't have to do anything > except writing some nice comment about this ;). You're right. I'm not sure what I got confused with there. I don't think there's a race I need to worry about ... even if another page gets instantiated (consider one thread furiously loading from a hole as fast as it can while another thread does a write), we'll shoot it down again. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org