public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bart.vanassche@wdc.com>
To: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	Jianchao Wang <jianchao.w.wang@oracle.com>,
	Ming Lei <ming.lei@redhat.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Johannes Thumshirn <jthumshirn@suse.de>
Subject: Re: [PATCH v3 4/9] percpu-refcount: Introduce percpu_ref_read()
Date: Thu, 2 Aug 2018 13:04:43 -0700	[thread overview]
Message-ID: <aa524e89-6626-ed22-ff46-25674354ba58@wdc.com> (raw)
In-Reply-To: <20180802190649.GV1206094@devbig004.ftw2.facebook.com>

On 08/02/18 12:06, Tejun Heo wrote:
> On Thu, Aug 02, 2018 at 11:29:39AM -0700, Bart Van Assche wrote:
>> Introduce a function that allows to read the value of a per-cpu counter.
>> This function will be used in the next patch to check whether a per-cpu
>> counter in atomic mode has the value one.
> 
> I'm not a big fan of exposing this.  If you need to test for atomic &&
> 1, I'd much prefer a helper specifically testing for that.  But can
> you please explain a bit why you need this?
Hello Tejun,

As you probably know one of the long term goals for the block layer is 
to switch to blk-mq and to drop the legacy block layer. Hence this patch 
series that adds support for runtime power management to blk-mq because 
today that feature is missing from blk-mq. The approach is the same as 
for the legacy block layer: if the autosuspend timer expires and no
requests are in flight, suspend the block device. So we need a mechanism 
to track whether or not any requests are in flight. One possible 
approach is to check the value of q_usage_counter. percpu_ref_is_zero() 
could only be used to check q_usage_counter if that counter would be 
switched to atomic mode first and if the initial reference would be 
dropped too. I want to avoid the overhead of that switch to atomic mode 
whenever possible. Hence the proposal to introduce the percpu_ref_read() 
function. If the value returned by that function is larger than one then 
we know that requests are in flight and hence that the switch to atomic 
mode can be skipped.

Proposals for alternative approaches are welcome.

Thanks,

Bart.

  reply	other threads:[~2018-08-02 20:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-02 18:29 [PATCH v3 0/9] blk-mq: Enable runtime power management Bart Van Assche
2018-08-02 18:29 ` [PATCH v3 1/9] block: Fix a comment in a header file Bart Van Assche
2018-08-02 18:29 ` [PATCH v3 2/9] block: Move power management functions into new source files Bart Van Assche
2018-08-02 18:29 ` [PATCH v3 3/9] block: Serialize queue freezing and blk_pre_runtime_suspend() Bart Van Assche
2018-08-02 18:29 ` [PATCH v3 4/9] percpu-refcount: Introduce percpu_ref_read() Bart Van Assche
2018-08-02 19:06   ` Tejun Heo
2018-08-02 20:04     ` Bart Van Assche [this message]
2018-08-06 17:18       ` Tejun Heo
2018-08-06 17:28         ` Bart Van Assche
2018-08-07 22:53         ` Bart Van Assche
2018-08-02 18:29 ` [PATCH v3 5/9] block, scsi: Rework runtime power management Bart Van Assche
2018-08-02 23:50   ` Ming Lei
2018-08-03 16:16     ` Bart Van Assche
2018-08-02 18:29 ` [PATCH v3 6/9] block: Warn if pm_runtime_get*() has not been called Bart Van Assche
2018-08-02 18:29 ` [PATCH v3 7/9] block: Remove blk_pm_requeue_request() Bart Van Assche
2018-08-02 18:29 ` [PATCH v3 8/9] blk-mq: Insert blk_pm_{add,put}_request() calls Bart Van Assche
2018-08-02 23:53   ` Ming Lei
2018-08-03  0:08     ` Bart Van Assche
2018-08-03  0:11       ` Ming Lei
2018-08-03  1:03         ` Bart Van Assche
2018-08-03  1:11           ` Ming Lei
2018-08-02 18:29 ` [PATCH v3 9/9] blk-mq: Enable support for runtime power management Bart Van Assche
2018-08-02 21:25 ` [PATCH v3 0/9] blk-mq: Enable " Jens Axboe

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=aa524e89-6626-ed22-ff46-25674354ba58@wdc.com \
    --to=bart.vanassche@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=jianchao.w.wang@oracle.com \
    --cc=jthumshirn@suse.de \
    --cc=linux-block@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=stern@rowland.harvard.edu \
    --cc=tj@kernel.org \
    /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