Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1501108 > unrolled thread

[PATCH] DAX: enable iostat for read/write

Back to article view | Back to linux.kernel

Contents

  [PATCH] DAX: enable iostat for read/write Toshi Kani <toshi.kani@hpe.com> - 2016-10-14 19:30 +0200
    Re: [PATCH] DAX: enable iostat for read/write Dan Williams <dan.j.williams@intel.com> - 2016-10-14 19:40 +0200
      Re: [PATCH] DAX: enable iostat for read/write "Kani, Toshimitsu" <toshi.kani@hpe.com> - 2016-10-14 20:50 +0200
    Re: [PATCH] DAX: enable iostat for read/write Dave Chinner <david@fromorbit.com> - 2016-10-15 10:00 +0200
      Re: [PATCH] DAX: enable iostat for read/write "Kani, Toshimitsu" <toshi.kani@hpe.com> - 2016-10-17 20:00 +0200
        Re: [PATCH] DAX: enable iostat for read/write Dan Williams <dan.j.williams@intel.com> - 2016-10-17 21:00 +0200
          Re: [PATCH] DAX: enable iostat for read/write "Kani, Toshimitsu" <toshi.kani@hpe.com> - 2016-10-17 21:30 +0200

#1501108 — [PATCH] DAX: enable iostat for read/write

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 <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
---
 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);
 

[toc] | [next] | [standalone]

#1501112

On Fri, Oct 14, 2016 at 10:25 AM, Toshi Kani <toshi.kani@hpe.com> 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 <toshi.kani@hpe.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> ---
>  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?

[toc] | [prev] | [next] | [standalone]

#1501142

On Fri, 2016-10-14 at 10:35 -0700, Dan Williams wrote:
> On Fri, Oct 14, 2016 at 10:25 AM, Toshi Kani <toshi.kani@hpe.com>
> 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 <toshi.kani@hpe.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> > ---
> >  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

[toc] | [prev] | [next] | [standalone]

#1501256

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 <toshi.kani@hpe.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> ---
>  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
david@fromorbit.com

[toc] | [prev] | [next] | [standalone]

#1502318

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...

[toc] | [prev] | [next] | [standalone]

#1502346

On Mon, Oct 17, 2016 at 10:40 AM, Kani, Toshimitsu <toshi.kani@hpe.com> 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.

[toc] | [prev] | [next] | [standalone]

#1502370

On Mon, 2016-10-17 at 11:55 -0700, Dan Williams wrote:
> On Mon, Oct 17, 2016 at 10:40 AM, Kani, Toshimitsu <toshi.kani@hpe.co
> 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web