[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YfFmaKkdqZPXB5B0@bender.morinfr.org>
Date: Wed, 26 Jan 2022 16:19:04 +0100
From: Guillaume Morin <guillaume@...infr.org>
To: Jack Wang <jack.wang.usish@...il.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org, stable <stable@...r.kernel.org>,
Guoqing Jiang <jiangguoqing@...inos.cn>,
Song Liu <song@...nel.org>,
Guillaume Morin <guillaume@...infr.org>
Subject: Re: [PATCH 5.10 01/25] md: revert io stats accounting
On 26 Jan 13:37, Jack Wang wrote:
> > > >
> > > > - if (bio->bi_end_io != md_end_io) {
> > > > - struct md_io *md_io;
> > > > -
> > > > - md_io = mempool_alloc(&mddev->md_io_pool, GFP_NOIO);
> > > > - md_io->mddev = mddev;
> > > > - md_io->orig_bi_end_io = bio->bi_end_io;
> > > > - md_io->orig_bi_private = bio->bi_private;
> > > > -
> > > > - bio->bi_end_io = md_end_io;
> > > > - bio->bi_private = md_io;
> > > > -
> > > > - md_io->start_time = part_start_io_acct(mddev->gendisk,
> > > > - &md_io->part, bio);
> > > > - }
> > > > -
> > > > + /*
> > > > + * save the sectors now since our bio can
> > > > + * go away inside make_request
> > > > + */
> > > > + sectors = bio_sectors(bio);
> > > This code snip is not inside the original patch, and it's not in
> > > latest upstream too.
> > > > /* bio could be mergeable after passing to underlayer */
> > > > bio->bi_opf &= ~REQ_NOMERGE;
> > > >
> > > > md_handle_request(mddev, bio);
> > > >
> > > > + part_stat_lock();
> > > > + part_stat_inc(&mddev->gendisk->part0, ios[sgrp]);
> > > > + part_stat_add(&mddev->gendisk->part0, sectors[sgrp], sectors);
> > > > + part_stat_unlock();
> > > > +
> > > same here, this code snip is not inside the original patch, and it's
> > > not in latest upstream too.
> >
> > Is it a problem?
> Not sure, might cause some confusion regarding io stats.
Have you observed anything weird? Because if you don't include this, I
don't see where these stats are updated at all. Could you explain
please?
--
Guillaume Morin <guillaume@...infr.org>
Powered by blists - more mailing lists