From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Hansson Date: Tue, 13 Dec 2011 15:18:26 +0000 Subject: Re: [PATCH/RFC] mmc: add a device PM QoS constraint when a host is Message-Id: <4EE76CC2.9080308@stericsson.com> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Guennadi Liakhovetski Cc: "linux-mmc@vger.kernel.org" , "linux-pm@vger.kernel.org" , Chris Ball , "linux-sh@vger.kernel.org" , "Rafael J. Wysocki" 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Hansson Subject: Re: [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed Date: Tue, 13 Dec 2011 16:18:26 +0100 Message-ID: <4EE76CC2.9080308@stericsson.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-sh-owner@vger.kernel.org To: Guennadi Liakhovetski Cc: "linux-mmc@vger.kernel.org" , "linux-pm@vger.kernel.org" , Chris Ball , "linux-sh@vger.kernel.org" , "Rafael J. Wysocki" List-Id: linux-mmc@vger.kernel.org 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 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