Vitaly Wool wrote:
On Wed, Dec 14, 2011 at 4:29 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxxxxxx<mailto:ulf.hansson@xxxxxxxxxxxxxx>> wrote:
I'm a bit pessimistic about this patch. What if we have a root filesystem on an SD card, or, what is a more common case, on an eMMC? How is it going to be handled?
This is handled for sure. I have verified this case and I agree that this is likely a common case.
In principle, every mmc/sd requests handled in issue_rq (block.c), will unless the host is not already resumed, do a "sync" of the resume work.
So in fact instead of decreasing time-to-userspace for resume, you are rather going to increase it in this case.
Nope, not true. :-)
Somewhere you need to handle the resume. Earlier it was done immediately
when getting the resume request, thus every host resume in the sequence
is added to the total time for userspace to be resumed.
I did some measurement, having two eMMC connected (one of them with a
root file system mounted) and one rather good SD-card with VFAT. The
resume time for the kernel before these patches were around 600 ms.
After my patches I had around 20 ms.
Moreover, I noticed very seldom than any mmc/sd request arrived within
the time were the deferred resumed has not been done. Of course this
will very much depend on what kind of userspace application that is
running and if there is an ongoing file transfer that were frozen when
doing suspend.
But, if this happens (deferred resume not done), the total resume time
for that particular userspace application will anyway be heavily
decreased since the other hosts resume time did not affect the resume
time for this application.
>
IMHO, at the end of the day this thing should either
- be capability-based (add MMC_CAP_...)
Why do someone not want this?
- be PM_QOS based
Why do someone not want this?
-be async (e. g. start card resume process in resume routine, set atomic, return success and have wait_event_interruptible_timeout in block_rq if this atomic is set).
Don't follow you. This is exactly what the patch is doing. Not just for
SD, but also for (e)MMC. I don't see your issue.
Anyway, in fact this patch is only addressing SD card case as of now which can be covered by runtime PM.
Nope, both SD and (e)MMC. How can runtime PM solve a normal suspend? It
has noting to do we each other I believe.
Thanks,
Vitaly
Br
Ulf Hansson
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
