From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751636AbdAMXQi (ORCPT ); Fri, 13 Jan 2017 18:16:38 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:49394 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751486AbdAMXQg (ORCPT ); Fri, 13 Jan 2017 18:16:36 -0500 Date: Fri, 13 Jan 2017 15:16:35 -0800 From: Andrew Morton To: "Kani, Toshimitsu" Cc: "linux-kernel@vger.kernel.org" , "linux-nvdimm@ml01.01.org" , "viro@zeniv.linux.org.uk" , "dan.j.williams@intel.com" , "joe@perches.com" , "linux-fsdevel@vger.kernel.org" , "ross.zwisler@linux.intel.com" , "david@fromorbit.com" Subject: Re: [PATCH v6] DAX: enable iostat for read/write Message-Id: <20170113151635.ef2a4559fd8bfc5b268141c1@linux-foundation.org> In-Reply-To: <1484352338.2029.7.camel@hpe.com> References: <20170113233418.32252-1-toshi.kani@hpe.com> <20170113145406.b1f065fb7fda67fd18830969@linux-foundation.org> <1484352338.2029.7.camel@hpe.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) 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 On Fri, 13 Jan 2017 23:09:58 +0000 "Kani, Toshimitsu" wrote: > On Fri, 2017-01-13 at 14:54 -0800, Andrew Morton wrote: > > On Fri, 13 Jan 2017 16:34:18 -0700 Toshi Kani > > wrote: > > > > > DAX IO path does not support iostat, but its metadata IO path does. > > > Therefore, iostat shows metadata IO statistics only, which has been > > > confusing to users. > > > > > > Add iostat support to the DAX read/write path. > > > > > > Note, iostat still does not support the DAX mmap path as it allows > > > user applications to access directly. > > > > > > ... > > > > > > --- a/fs/dax.c > > > +++ b/fs/dax.c > > > @@ -1058,12 +1058,24 @@ dax_iomap_rw(struct kiocb *iocb, struct > > > iov_iter *iter, > > > __{ > > > __ struct address_space *mapping = iocb->ki_filp->f_mapping; > > > __ struct inode *inode = mapping->host; > > > + struct gendisk *disk = inode->i_sb->s_bdev->bd_disk; > > > __ loff_t pos = iocb->ki_pos, ret = 0, done = 0; > > > __ unsigned flags = 0; > > > + unsigned long start = 0; > > > + int do_acct = blk_queue_io_stat(disk->queue); > > > > (The poorly named) blk_queue_io_stat() actually returns a bool.____This > > is well concealed because blk_queue_io_stat() is unnecessarily > > implemented as a macro (why oh why). > > It was unclear to me what type I needed to use. test_bit() is 'bool' > in arch/x86/include/asm/bitops.h but is 'int' in include/asm- > generic/bitops/non-atomic.h. So, I used 'int' for safe... Yes, x86 does appear to be an outlier. Mess.