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.
Signed-off-by: Toshi Kani <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Alexander Viro <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Ross Zwisler <[email protected]>
---
fs/dax.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/fs/dax.c b/fs/dax.c
index 014defd..3aaaac2 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -144,6 +144,34 @@ static sector_t to_sector(const struct buffer_head *bh,
return sector;
}
+static void dax_iostat_start(struct gendisk *disk, struct iov_iter *iter,
+ unsigned long *start)
+{
+ int rw = iov_iter_rw(iter);
+ int sec = iov_iter_count(iter) >> 9;
+ int cpu = part_stat_lock();
+
+ *start = jiffies;
+ part_round_stats(cpu, &disk->part0);
+ part_stat_inc(cpu, &disk->part0, ios[rw]);
+ part_stat_add(cpu, &disk->part0, sectors[rw], sec);
+ part_inc_in_flight(&disk->part0, rw);
+ part_stat_unlock();
+}
+
+static void dax_iostat_end(struct gendisk *disk, struct iov_iter *iter,
+ unsigned long start)
+{
+ unsigned long duration = jiffies - start;
+ int rw = iov_iter_rw(iter);
+ int cpu = part_stat_lock();
+
+ part_stat_add(cpu, &disk->part0, ticks[rw], duration);
+ part_round_stats(cpu, &disk->part0);
+ part_dec_in_flight(&disk->part0, rw);
+ part_stat_unlock();
+}
+
static ssize_t dax_io(struct inode *inode, struct iov_iter *iter,
loff_t start, loff_t end, get_block_t get_block,
struct buffer_head *bh)
@@ -265,9 +293,12 @@ ssize_t dax_do_io(struct kiocb *iocb, struct inode *inode,
ssize_t retval = -EINVAL;
loff_t pos = iocb->ki_pos;
loff_t end = pos + iov_iter_count(iter);
+ struct gendisk *disk;
+ unsigned long start = 0;
memset(&bh, 0, sizeof(bh));
bh.b_bdev = inode->i_sb->s_bdev;
+ disk = bh.b_bdev->bd_disk;
if ((flags & DIO_LOCKING) && iov_iter_rw(iter) == READ)
inode_lock(inode);
@@ -276,8 +307,14 @@ ssize_t dax_do_io(struct kiocb *iocb, struct inode *inode,
if (!(flags & DIO_SKIP_DIO_COUNT))
inode_dio_begin(inode);
+ if (blk_queue_io_stat(disk->queue))
+ dax_iostat_start(disk, iter, &start);
+
retval = dax_io(inode, iter, pos, end, get_block, &bh);
+ if (start)
+ dax_iostat_end(disk, iter, start);
+
if ((flags & DIO_LOCKING) && iov_iter_rw(iter) == READ)
inode_unlock(inode);
On Fri, Oct 14, 2016 at 10:25 AM, Toshi Kani <[email protected]> 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.
>
> Signed-off-by: Toshi Kani <[email protected]>
> Cc: Andrew Morton <[email protected]>
> Cc: Alexander Viro <[email protected]>
> Cc: Dan Williams <[email protected]>
> Cc: Ross Zwisler <[email protected]>
> ---
> fs/dax.c | 37 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 014defd..3aaaac2 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -144,6 +144,34 @@ static sector_t to_sector(const struct buffer_head *bh,
> return sector;
> }
>
> +static void dax_iostat_start(struct gendisk *disk, struct iov_iter *iter,
> + unsigned long *start)
> +{
> + int rw = iov_iter_rw(iter);
> + int sec = iov_iter_count(iter) >> 9;
Should this be a minimum of one sector since we allow unaligned
transfers through this interface?
...or is iov_iter_count() somehow guaranteed to be sector aligned here?
On Fri, 2016-10-14 at 10:35 -0700, Dan Williams wrote:
> On Fri, Oct 14, 2016 at 10:25 AM, Toshi Kani <[email protected]>
> 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.
> >
> > Signed-off-by: Toshi Kani <[email protected]>
> > Cc: Andrew Morton <[email protected]>
> > Cc: Alexander Viro <[email protected]>
> > Cc: Dan Williams <[email protected]>
> > Cc: Ross Zwisler <[email protected]>
> > ---
> > fs/dax.c | 37 +++++++++++++++++++++++++++++++++++++
> > 1 file changed, 37 insertions(+)
> >
> > diff --git a/fs/dax.c b/fs/dax.c
> > index 014defd..3aaaac2 100644
> > --- a/fs/dax.c
> > +++ b/fs/dax.c
> > @@ -144,6 +144,34 @@ static sector_t to_sector(const struct
> > buffer_head *bh,
> > return sector;
> > }
> >
> > +static void dax_iostat_start(struct gendisk *disk, struct iov_iter
> > *iter,
> > + unsigned long *start)
> > +{
> > + int rw = iov_iter_rw(iter);
> > + int sec = iov_iter_count(iter) >> 9;
>
> Should this be a minimum of one sector since we allow unaligned
> transfers through this interface?
>
> ...or is iov_iter_count() somehow guaranteed to be sector aligned
> here?
You are right. I will update to set a minimum of one sector in v2.
Thanks!
-Toshi
On Fri, Oct 14, 2016 at 11:25:13AM -0600, 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.
>
> Signed-off-by: Toshi Kani <[email protected]>
> Cc: Andrew Morton <[email protected]>
> Cc: Alexander Viro <[email protected]>
> Cc: Dan Williams <[email protected]>
> Cc: Ross Zwisler <[email protected]>
> ---
> fs/dax.c | 37 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 014defd..3aaaac2 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -144,6 +144,34 @@ static sector_t to_sector(const struct buffer_head *bh,
> return sector;
> }
>
> +static void dax_iostat_start(struct gendisk *disk, struct iov_iter *iter,
> + unsigned long *start)
> +{
> + int rw = iov_iter_rw(iter);
> + int sec = iov_iter_count(iter) >> 9;
> + int cpu = part_stat_lock();
> +
> + *start = jiffies;
> + part_round_stats(cpu, &disk->part0);
> + part_stat_inc(cpu, &disk->part0, ios[rw]);
> + part_stat_add(cpu, &disk->part0, sectors[rw], sec);
> + part_inc_in_flight(&disk->part0, rw);
> + part_stat_unlock();
> +}
Why reimplement generic_start_io_acct() and generic_end_io_acct()?
-Dave.
--
Dave Chinner
[email protected]
On Sat, 2016-10-15 at 18:54 +1100, Dave Chinner wrote:
> On Fri, Oct 14, 2016 at 11:25:13AM -0600, Toshi Kani wrote:
:
> > +static void dax_iostat_start(struct gendisk *disk, struct iov_iter
> > *iter,
> > + unsigned long *start)
> > +{
> > + int rw = iov_iter_rw(iter);
> > + int sec = iov_iter_count(iter) >> 9;
> > + int cpu = part_stat_lock();
> > +
> > + *start = jiffies;
> > + part_round_stats(cpu, &disk->part0);
> > + part_stat_inc(cpu, &disk->part0, ios[rw]);
> > + part_stat_add(cpu, &disk->part0, sectors[rw], sec);
> > + part_inc_in_flight(&disk->part0, rw);
> > + part_stat_unlock();
> > +}
>
> Why reimplement generic_start_io_acct() and generic_end_io_acct()?
It was modeled after __nd_iostat_start() / nd_iostart_end(). I agree
that we can use generic_start_io_acct() and generic_end_io_acct() here.
Should we also change the nd interface to use the generic version as
well?
Thanks,
-Toshi
ps.
Sorry I realized this comment after sending out v2...
On Mon, Oct 17, 2016 at 10:40 AM, Kani, Toshimitsu <[email protected]> wrote:
> On Sat, 2016-10-15 at 18:54 +1100, Dave Chinner wrote:
>> On Fri, Oct 14, 2016 at 11:25:13AM -0600, Toshi Kani wrote:
> :
>> > +static void dax_iostat_start(struct gendisk *disk, struct iov_iter
>> > *iter,
>> > + unsigned long *start)
>> > +{
>> > +int rw = iov_iter_rw(iter);
>> > +int sec = iov_iter_count(iter) >> 9;
>> > +int cpu = part_stat_lock();
>> > +
>> > +*start = jiffies;
>> > +part_round_stats(cpu, &disk->part0);
>> > +part_stat_inc(cpu, &disk->part0, ios[rw]);
>> > +part_stat_add(cpu, &disk->part0, sectors[rw], sec);
>> > +part_inc_in_flight(&disk->part0, rw);
>> > +part_stat_unlock();
>> > +}
>>
>> Why reimplement generic_start_io_acct() and generic_end_io_acct()?
>
> It was modeled after __nd_iostat_start() / nd_iostart_end(). I agree
> that we can use generic_start_io_acct() and generic_end_io_acct() here.
>
> Should we also change the nd interface to use the generic version as
> well?
Yes, sounds good to me.
On Mon, 2016-10-17 at 11:55 -0700, Dan Williams wrote:
> On Mon, Oct 17, 2016 at 10:40 AM, Kani, Toshimitsu <[email protected]
> m> wrote:
> >
> > On Sat, 2016-10-15 at 18:54 +1100, Dave Chinner wrote:
> > >
> > > On Fri, Oct 14, 2016 at 11:25:13AM -0600, Toshi Kani wrote:
> > :
> > >
> > > >
> > > > +static void dax_iostat_start(struct gendisk *disk, struct
> > > > iov_iter
> > > > *iter,
> > > > + unsigned long *start)
> > > > +{
> > > > +int rw = iov_iter_rw(iter);
> > > > +int sec = iov_iter_count(iter) >> 9;
> > > > +int cpu = part_stat_lock();
> > > > +
> > > > +*start = jiffies;
> > > > +part_round_stats(cpu, &disk->part0);
> > > > +part_stat_inc(cpu, &disk->part0, ios[rw]);
> > > > +part_stat_add(cpu, &disk->part0, sectors[rw], sec);
> > > > +part_inc_in_flight(&disk->part0, rw);
> > > > +part_stat_unlock();
> > > > +}
> > >
> > > Why reimplement generic_start_io_acct() and
> > > generic_end_io_acct()?
> >
> > It was modeled after __nd_iostat_start() / nd_iostart_end(). I
> > agree that we can use generic_start_io_acct() and
> > generic_end_io_acct() here.
> >
> > Should we also change the nd interface to use the generic version
> > as well?
>
> Yes, sounds good to me.
Will do. Thanks!
-Toshi