linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Mikulas Patocka <mpatocka@redhat.com>,
	dm-devel@redhat.com, linux-block@vger.kernel.org
Subject: Re: [PATCH v2 4/6] block: switch to per-cpu in-flight counters
Date: Wed, 5 Dec 2018 13:03:47 -0500	[thread overview]
Message-ID: <20181205180347.GA9966@redhat.com> (raw)
In-Reply-To: <eb184c39-9d60-0fa3-0d27-7af2f78d601e@kernel.dk>

On Wed, Dec 05 2018 at 12:54pm -0500,
Jens Axboe <axboe@kernel.dk> wrote:

> On 12/5/18 10:49 AM, Mike Snitzer wrote:
> > On Wed, Dec 05 2018 at 12:30pm -0500,
> > Jens Axboe <axboe@kernel.dk> wrote:
> > 
> >> There's also no need to pass in the cpu, if we're not running with
> >> preempt disabled already we have a problem. 
> > 
> > Why should this be any different than the part_stat_* interfaces?
> > __part_stat_add(), part_stat_read(), etc also use
> > per_cpu_ptr((part)->dkstats, (cpu) accessors.
> 
> Maybe audit which ones actually need it? To answer the specific question,
> it's silly to pass in the cpu, if we're pinned already. That's true
> both programatically, but also for someone reading the code.

I understand you'd like to avoid excess interface baggage.  But seems to
me we'd be better off being consistent, when extending the percpu
portion of block core stats, and then do an incremental to clean it all
up.

But I'm open to doing it however you'd like if you feel strongly about
how this should be done.

Mike

  reply	other threads:[~2018-12-05 18:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-28  0:42 [PATCH 0/3] per-cpu in_flight counters for bio-based drivers Mikulas Patocka
2018-11-30 14:43 ` Mike Snitzer
2018-11-30 15:50   ` Mike Snitzer
2018-11-30 19:57     ` Mike Snitzer
2018-11-30 22:22 ` [PATCH v2 0/6] " Mike Snitzer
2018-11-30 22:22   ` [PATCH v2 1/6] dm: dont rewrite dm_disk(md)->part0.in_flight Mike Snitzer
2018-11-30 22:22   ` [PATCH v2 2/6] dm rq: leverage blk_mq_queue_busy() to check for outstanding IO Mike Snitzer
2018-11-30 22:22   ` [PATCH v2 3/6] block: delete part_round_stats and switch to less precise counting Mike Snitzer
2018-11-30 22:22   ` [PATCH v2 4/6] block: switch to per-cpu in-flight counters Mike Snitzer
2018-12-05 17:30     ` Jens Axboe
2018-12-05 17:49       ` Mike Snitzer
2018-12-05 17:54         ` Jens Axboe
2018-12-05 18:03           ` Mike Snitzer [this message]
2018-12-05 18:04             ` Jens Axboe
2018-12-05 18:18               ` Mike Snitzer
2018-12-05 18:35                 ` Jens Axboe
2018-11-30 22:22   ` [PATCH v2 5/6] block: return just one value from part_in_flight Mike Snitzer
2018-11-30 22:22   ` [PATCH v2 6/6] dm: remove the pending IO accounting Mike Snitzer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181205180347.GA9966@redhat.com \
    --to=snitzer@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).