Hi!

>> Well, you kind of need both.
> Periodical check is a complement, not a replacement.

Then we are indeed in agreement.

> Must BKOPS always be deferred until performance is impacted?

No, of course not. As you say doing BKOPS too late is not good, but
also doing them too often is probably not wise either (will cause
latency for interrupting BKOPS for too many requests in that case).

> About starvation.
> What happens if the BKOPS never have time to finish because new writes
> are coming in all the time. Is it possible to starve the
> BKOPS-operation?
> Will it come to a point when BKOPS must run without interruption?

The 4.5 spec says that if the level is at critical then some
operations may extend beyond their original timeouts due to
undelayable maintenance operations. So I can not forsee that an eMMC
might stop working because the level reached critical and the host did
not start BKOPS periodically. So as far as I understand it you may HPI
interrupt BKOPS at critical level in order to issue CMD25
(WRITE_MULTIPLE_BLOCK), but there is a good chance that this write
will take a long time to complete.

> One question is:
> Is it worth running BKOPS if the BKOPS_STATUS is only 1? I could run
> some tests comparing write performance when status is 0,1,2.

The spec is likely intentionally arbitrary about what these levels
mean in order to allow vendors to implement those differently.

> I don't know what the best place would be for a BKOPS_STATUS check.
> What comes to my mind is to use the same credentials that are used for
> power save.

That seems like a good option, yes.

> Suspend? if suspend is requested one might check BKOPS_STATUS and
> return -EBUSY if BKOPS needs to be started.

Maybe, one could also choose to do this based on the level of course.

However now that I'm thinking about it, I don't think Jaehoon has
taken care of the case where suspend happens while BKOPS are running
in the background. I guess one has to issue HPI in that case to stop
the BKOPS before going in to suspend, otherwise one risks cutting
power to the card while BKOPS are running.

 / Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to