2012/2/24 Saugata Das <saugata.das@xxxxxxxxxx>: > Hi Jaehoon > > Since you are planning to rework this patch, can you consider to > implement the periodic BKOPS level check and triggering BKOPS at level > 1 when the queue is idle ? Hi Saugata, Sure..i'm considering them.. I have implemented and tested the periodic bkops level. It should be included in patch-v8. Thank you for comments. Best Regards, Jaehoon Chung > > > On 24 February 2012 14:08, Jaehoon Chung <jh80.chung@xxxxxxxxxxx> wrote: >> On 02/23/2012 06:05 PM, Adrian Hunter wrote: >> >>> On 23/02/12 04:21, Jaehoon Chung wrote: >>>> On 02/22/2012 11:11 PM, Adrian Hunter wrote: >>>> >>>>> On 20/01/12 08:48, Jaehoon Chung wrote: >>>>>> Enable eMMC background operations (BKOPS) feature. >>>>>> >>>>>> If URGENT_BKOPS is set after a response, note that BKOPS >>>>>> are required. After all I/O requests are finished, run >>>>>> BKOPS if required. Should read/write operations be requested >>>>>> during BKOPS, first issue HPI to interrupt the ongoing BKOPS >>>>>> and then service the request. >>>>> >>>>> You are leaving bkops running and releasing the host. Won't >>>>> that cause problems for other entry points to mmc services >>>>> e.g. system suspend (cache control, sleep etc), ioctl, sysfs, >>>>> etc >>>> >>>> I see. i will complement for your review. >>> >>> Please cc me. >> >> Sure.. >> >>> >>>> Didn't you have the other comment? >>> >>> Well, yes. I also suggest: >>> - don't use host->lock spin lock at all >>> - claim the host in the caller not in >>> mmc_start_bkops() >>> >>> But the main issues are design issues not implementation. >>> i.e. >>> - always run bkops at level 3 before doing any >>> other requests - that requirement should probably >>> be implemented in core rather than the block driver >> >> In core..it's reasonable..i will try that. >> >>> - do not release the host while bkops are running >> >> Right..don't release the host. i will consider. >> >>> >>> And a new one: >>> - how do you know that trim/discard/sanitize will not >>> result in a need for bkops? >> >> Well, i didn't consider that case. >> but i think that need to control them. >> >> Thanks for comments. >> >> Best Regards, >> Jaehoon Chung >> >>> >>> -- >>> 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 >>> >> >> >> -- >> 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 > -- > 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 -- 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
