Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752511AbcD2Qa3 (ORCPT ); Fri, 29 Apr 2016 12:30:29 -0400 Received: from g2t4623.austin.hp.com ([15.73.212.78]:51075 "EHLO g2t4623.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752327AbcD2Q2Q (ORCPT ); Fri, 29 Apr 2016 12:28:16 -0400 From: Waiman Long To: "Theodore Ts'o" , Andreas Dilger , Alexander Viro , Matthew Wilcox Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, Dave Chinner , Christoph Hellwig , Scott J Norton , Douglas Hatch , Toshimitsu Kani , Waiman Long Subject: [PATCH v5 1/2] dax: Don't touch i_dio_count in dax_do_io() Date: Fri, 29 Apr 2016 12:27:55 -0400 Message-Id: <1461947276-25988-2-git-send-email-Waiman.Long@hpe.com> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1461947276-25988-1-git-send-email-Waiman.Long@hpe.com> References: <1461947276-25988-1-git-send-email-Waiman.Long@hpe.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2141 Lines: 57 The purpose of the i_dio_count is to protect against truncation while the I/O operation is in progress. As dax_do_io() only does synchronous I/O, the locking performed by the caller or within dax_do_io() for read should be enough to protect it against truncation. There is no need to touch the i_dio_count. Eliminating two atomic operations can sometimes give a noticeable improvement in I/O performance as NVDIMM is much faster than other disk devices. Suggested-by: Christoph Hellwig Signed-off-by: Waiman Long --- fs/dax.c | 14 ++++++-------- 1 files changed, 6 insertions(+), 8 deletions(-) diff --git a/fs/dax.c b/fs/dax.c index 90322eb..1b4b500 100644 --- a/fs/dax.c +++ b/fs/dax.c @@ -253,8 +253,12 @@ static ssize_t dax_io(struct inode *inode, struct iov_iter *iter, * If @flags has DIO_LOCKING set, we assume that the i_mutex is held by the * caller for writes. For reads, we take and release the i_mutex ourselves. * If DIO_LOCKING is not set, the filesystem takes care of its own locking. - * As with do_blockdev_direct_IO(), we increment i_dio_count while the I/O - * is in progress. + * + * The do_blockdev_direct_IO() function increment i_dio_count while the I/O + * is in progress. However, the dax_do_io() always does synchronous I/O. The + * locking done by the caller or within dax_do_io() for read (DIO_LOCKING) + * should be enough to protect against concurrent truncation. We don't really + * need to touch i_dio_count here. */ ssize_t dax_do_io(struct kiocb *iocb, struct inode *inode, struct iov_iter *iter, loff_t pos, get_block_t get_block, @@ -277,10 +281,6 @@ ssize_t dax_do_io(struct kiocb *iocb, struct inode *inode, } } - /* Protects against truncate */ - if (!(flags & DIO_SKIP_DIO_COUNT)) - inode_dio_begin(inode); - retval = dax_io(inode, iter, pos, end, get_block, &bh); if ((flags & DIO_LOCKING) && iov_iter_rw(iter) == READ) @@ -294,8 +294,6 @@ ssize_t dax_do_io(struct kiocb *iocb, struct inode *inode, retval = err; } - if (!(flags & DIO_SKIP_DIO_COUNT)) - inode_dio_end(inode); out: return retval; } -- 1.7.1