Hi Linus, On 11/22/2016 09:49 PM, Linus Walleij wrote: > On Tue, Nov 22, 2016 at 9:49 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >> On 22 November 2016 at 04:53, Jaehoon Chung <jh80.chung@xxxxxxxxxxx> wrote: > >>>> Correct, in general there is no value in using packed for Read. >>>> But I can’t say this for all existing flash management solution. >>>> The eMMC spec allows to use it for Read as well. >>> >>> As i know, when packed command had implemented, early eMMC had the firmware problem >>> for Packed Read operation. but so I can't say Packed Read doesn't have the benefit for performance. >>> But Packed Write command can see the benefit for performance. >> >> Regarding "performance", are you merely thinking about increased >> throughput? With packed command we decrease the communication overhead >> with the card so less commands becomes sent/received. >> >> Or, did you also observed an improved behaviour of the card from a >> garbage collect point of view? In other words also a decreased latency >> when the device is becoming more and more used? >> >> Finally, did you compare the packed command, towards using the >> asynchronous request mechanisms (using the ->pre|post_req() mmc host >> ops)? > > Packed write (and read, if we had implemented it) can only happen when > we get a number of requests to different areas of the card. > > If they are to consecutive sectors (such as with a dd-test) it will not > improve performance, as that case is already optimized by the block > layer by front-merging of the requests into large chunks, I guess? > > Indeed commit ce39f9d17c14 mentions improvement on lmdd but not > how it was invoked. I suspect it was invoked with random writes... Well, I don't know those improvements was right or not.. > > It is important to do everything we can to improve random small writes > though, and it seems packed command can do that. Agreed...but i have checked with latest kernel and older version(v3.18). I saw the random write performance with small chunk size was increased with v3.18, not v4.9-rc5. I don't know what happens. > > (...) >>> Actually, some shipping Samsung devices with eMMC4.5 might be used packed command. >>> (For Android/Tizen OS and ARTIK boards) >> >> Thanks for sharing this information! >> >> It seems like we need to run another round of performance >> measurements, as to get some fresh number of the benefit of packed >> command. >> I would really appreciate if you could help out with that. > > I would add: do it on the upstream kernel and submit the stuff needed > to make it work for you out-of-the box. > > This is on Exynos I guess? > > Can we have this flag set for the Exynos host controller, and/or > proper DT bindings to mark it as packed command enabled? Actually, I can add the property or flags..but i think it's meaningless.. If you ask me my opinion, i don't want to add the enabling packed command at this time. Because i didn't see the increasing performance dynamically at this time. But i can say..when we had applied the packed command (2~3years ago.), there were some benefit to use this command. Yes..my comments might be confused.. but i just mentioned about some Samsung guys are using packed command for their devices with eMMC4.5. I'm not sure which kernel version they used..maybe older version. > > Hell I don't even know if this is a feature that needs anything special > from the host controller. Does it? Should we rather just enable it for all > host controllers if the card supports packed command? I'm lost. > I'm also feeling likes you...Now I'm checking about performance with all exynos devices that i have. Best Regards, Jaehoon Chung > Yours, > Linus Walleij > -- > 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
