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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
