Re: [PATCH V2 2/2] mmc: Minimize resume-time by deferring resume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux