From: Lin Ming <ming.m.lin@intel.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Jens Axboe <axboe@kernel.dk>, 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: Thu, 17 May 2012 00:12:10 +0800 [thread overview]
Message-ID: <1337184730.4047.21.camel@hp6530s> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1205161156480.1852-100000@iolanthe.rowland.org>
On Wed, 2012-05-16 at 11:59 -0400, 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.
And the timer is restarted when we resume the device, right?
>
> Alan Stern
>
next prev parent reply other threads:[~2012-05-16 16:12 UTC|newest]
Thread overview: 27+ 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 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 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 14:28 ` Alan Stern
2012-05-16 15:40 ` Lin Ming
2012-05-16 15:59 ` Alan Stern
2012-05-16 15:59 ` Alan Stern
2012-05-16 16:12 ` Lin Ming [this message]
2012-05-16 18:29 ` 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=1337184730.4047.21.camel@hp6530s \
--to=ming.m.lin@intel.com \
--cc=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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.