2011/10/20 Andrei Warkentin <awarken...@vmware.com>: > ----- Original Message ----- >> From: "Praveen G K" <praveen...@gmail.com> >> To: "Andrei E. Warkentin" <andrey.warken...@gmail.com> >> Cc: "J Freyensee" <james_p_freyen...@linux.intel.com>, "Andrei Warkentin" >> <awarken...@vmware.com>, "Per Förlin" >> <per.for...@stericsson.com>, "Linus Walleij" <linus.wall...@linaro.org>, >> linux-mmc@vger.kernel.org, "Arnd Bergmann" >> <a...@arndb.de>, "Jon Medhurst" <t...@linaro.org> >> Sent: Thursday, October 20, 2011 11:10:02 AM >> Subject: Re: slow eMMC write speed >> >> 2011/10/20 Andrei E. Warkentin <andrey.warken...@gmail.com>: >> > 2011/10/19 Praveen G K <praveen...@gmail.com>: >> >> Also, can somebody please tell me the significance of >> >> blk_end_request? Thanks. >> >> Why do we call this after every block read or write? >> > >> > Because you want to update the struct request with the amount >> > written/read. If the entire >> > requested I/O range has been satiffied, blk_end_request also calls >> > blk_finish_request and >> > completes the request. >> Just for a quick understanding, I did the following >> >> During every eMMC write, I called the multi block write command with >> the same set of data, and I called the mmc_end_request > > What's mmc_end_request? I'm assuming you meant blk_end_request. Yes, you are right. I meant blk_end_request.
>> after let's >> say every 10 transfers (with each transfer being 128 blocks). I >> noticed that I did not see those big busy wait times as frequently as >> compared to calling blk_end_request after every 128 block was >> transferred. Why is that happening? > > So you did 10 back-to-back 64k transfers inside the request handling routine, > and you noticed that caused a smaller GC delay > rather than doing 10 separate multiblock 64k transfers the normal way? That's right. Even though the request is supposed to service only 64k, I sent 10 write commands each with 64k and then completed the request (within the loop that takes care of the read/writes in block.c) with the same data. So, instead of calling blk_end_request just after one write, I call blk_end_request after 10 writes. > Depends. Maybe mmc_host_lazy_disable() (called by mmc_release_host) ends up > doing some power management, which is bound > to affect the card as well. > > Or maybe the card is trying to optimize consecutive writes into one larger > write internally, and you're crossing some internal > timestamp checking logic that distinguishes between separate and consecutive > writes. You should talk to your manufacturer, and investigate what happens to > your host on mmc_release_host. > > A > -- 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