linux-sh.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@stericsson.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Chris Ball <cjb@laptop.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [PATCH/RFC] mmc: add a device PM QoS constraint when a host is
Date: Tue, 13 Dec 2011 15:18:26 +0000	[thread overview]
Message-ID: <4EE76CC2.9080308@stericsson.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1112121642080.10378@axis700.grange>

Guennadi Liakhovetski wrote:
> Some MMC hosts implement a fine-grained runtime PM, whereby they
> runtime-suspend and -resume the host interface on each transfer. This can
> negatively affect performance, if the user was trying to transfer data
> blocks back-to-back. This patch adds a PM QoS constraint to avoid such a
> throughput reduction. This constraint prevents runtime-suspending the
> device, if the expected wakeup latency is larger than 100us.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>

I think host drivers can use autosuspend with some ms delay for this 
instead. This will mean that requests coming in bursts will not be 
affected (well only the first request in the burst will suffer from the 
runtime resume latency).

I believe that runtime resume callback should ofcourse be optimized so 
they are executed as fast as possible. But moreover, if they take more 
100us, is that really a reason for not executing them at all?

Br
Ulf Hansson

  reply	other threads:[~2011-12-13 15:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-12 15:46 [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first Guennadi Liakhovetski
2011-12-13 15:18 ` Ulf Hansson [this message]
2011-12-13 16:13   ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is Guennadi Liakhovetski
2011-12-13 21:08     ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed Rafael J. Wysocki
2011-12-14  9:00     ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is Ulf Hansson
2011-12-14  9:27       ` Linus Walleij
2011-12-14 10:28         ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed Rafael J. Wysocki
2011-12-14 15:50           ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is Linus Walleij
2011-12-14 10:15       ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed Rafael J. Wysocki
2011-12-14 11:12         ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is Ulf Hansson
2011-12-14 21:36           ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed Rafael J. Wysocki
2011-12-16  9:14             ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is Guennadi Liakhovetski
2011-12-19 12:17               ` Ulf Hansson
2012-03-03 20:53                 ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed Rafael J. Wysocki

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=4EE76CC2.9080308@stericsson.com \
    --to=ulf.hansson@stericsson.com \
    --cc=cjb@laptop.org \
    --cc=g.liakhovetski@gmx.de \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=rjw@sisk.pl \
    /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).