From: Jens Axboe <axboe@kernel.dk>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Lin Ming <ming.m.lin@intel.com>, Jeff Moyer <jmoyer@redhat.com>,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
linux-scsi@vger.kernel.org
Subject: Re: [RFC PATCH 3/3] block: add queue idle timer
Date: Wed, 16 May 2012 20:29:27 +0200 [thread overview]
Message-ID: <4FB3F207.7020308@kernel.dk> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1205161156480.1852-100000@iolanthe.rowland.org>
On 2012-05-16 17:59, Alan Stern wrote:
> On Wed, 16 May 2012, Lin Ming wrote:
>
>>> Lin, you should have more slack timer handling. Look at the blk-timeout
>>> handling of request timeouts for inspiration, and/or the thread that
>>> Jeff also references. Doing a timer add/del for each request put is a no
>>> go.
>>
>> You mentioned how to detect queue idle in the referenced thread:
>>
>> ===
>> So we could probably add an idle timer that is set to some suitable
>> timeout for this and would be added when the queue first goes empty. If
>> new requests come in, just let it simmer and defer checking the state to
>> when it actually fires.
>
> That is basically how the runtime PM timer works, if you use it as I
> described earlier.
>
>> ===
>>
>> What do you mean of "the queue first goes empty"?
>
> When the queue is first created, the timer is started.
>
> Whenever the timer expires, the code checks to see if any requests have
> been processed since the previous expiration. If they have, the timer
> is restarted. If they haven't, you suspend the device.
That sounds ideal, since you don't have to manage it in the block layer
then.
Lin, you should just use that. My suggestion was that you add the timer
when the queue first goes idle, IFF it isn't already running. When it
expires, you check last activity and decide whether to suspend it or
reset the timer. This is a more optimal than continually adding and
deleting timers, or even just moving it forwards 20s all the time. But
if pm already has support for this type of functionality (and it does,
Alan says, which makes sense since this mechanism would be useful for
other edvices), then you should indeed just use that.
--
Jens Axboe
prev parent reply other threads:[~2012-05-16 18:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-15 8:48 [RFC PATCH 0/3] block layer runtime pm Lin Ming
2012-05-15 8:48 ` [RFC PATCH 1/3] block: add a flag to identify PM request Lin Ming
2012-05-15 14:35 ` Alan Stern
2012-05-15 15:33 ` Lin Ming
2012-05-15 15:37 ` Alan Cox
2012-05-15 15:58 ` Lin Ming
2012-05-15 18:30 ` Alan Stern
2012-05-15 16:03 ` Alan Stern
2012-05-15 8:48 ` [RFC PATCH 2/3] block: add queue runtime pm callback Lin Ming
2012-05-15 14:37 ` Alan Stern
2012-05-15 15:36 ` Lin Ming
2012-05-15 8:48 ` [RFC PATCH 3/3] block: add queue idle timer Lin Ming
2012-05-15 14:39 ` Alan Stern
2012-05-15 15:49 ` Lin Ming
2012-05-15 19:19 ` Jeff Moyer
2012-05-16 1:27 ` Lin Ming
2012-05-16 13:04 ` Jeff Moyer
2012-05-16 13:53 ` Jens Axboe
2012-05-16 14:28 ` Alan Stern
2012-05-16 15:40 ` Lin Ming
2012-05-16 15:59 ` Alan Stern
2012-05-16 16:12 ` Lin Ming
2012-05-16 18:29 ` Jens Axboe [this message]
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=4FB3F207.7020308@kernel.dk \
--to=axboe@kernel.dk \
--cc=jmoyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=stern@rowland.harvard.edu \
/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).