If you got this half written reply, please ignore it.
BR
Ulf Hansson
Ulf Hansson wrote:
Vitaly Wool wrote:
Hi,
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.
What do you call "resume time" in this case?
Total kernel resume time.
This is an artificial and unfair definition. No one should care about
that. You can think of a time-to-splashscreen or
time-to-functional-userspace and both are not going to be improved
much with your patch if we run off of a eMMC-based root.
I think you are missing a very valuable thing about how the resume
sequence is being changed with this patch.
Before this patch:
_Every_ MMC and SD card were resumed sequentially. Thus every resume for
every card adds up to the resume time _always_.
After this patch:
1. MMC and SD cards can be is resumed in parallel.
2. Only MMC and SD cards which will get requests within ~3 s after the
kernel has resumed will notice the resume time. Requests triggered later
will be performed on a already resumed host.done coming
moreover, only if there arrives a request for before
only tho No resume is forst of all only done if there is a request
So for some reas and that the resume time (and also the the time for use
in a sequence
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.
...or the wakeup source was the userspace alarm etc. etc.
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.
I take that by "other hosts" you mean SD card? :)
"Other hosts", are all those hosts holding an eMMC/MMC or an SD-card,
but not that host that there were a request for, before the deferred
resume has finalized.
Ok, what if a rootfs application to be started first has to re-read
say certificates from the SD card? And what if not doing that in time
means QoS degradation?
No, you don't see all the _real_ use cases that you can break with
your patch.
-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.
No it doesn't. It defers the execution by arbitrary chosen time of 3
seconds.
Do you mean that we should implement this for SD cards as well?
Anyway, I don't understand what this should prevent a resume from
being executed for SD/SDIO/(e)MMC at all?
Please elaborate.
I'm not going to, at least not in this thread. The method you propose
is a hack and it can not be accepted at least because it doesn't give
a damn about QoS. The whole idea of "let's unconditionally defer
resume of something for arbitrary amount of time no matter what" is
invalid.
Thanks, Vitaly
--
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
