On 09/29/2011 09:24 AM, Linus Walleij wrote: > On Wed, Sep 28, 2011 at 11:34 PM, J Freyensee > <james_p_freyensee@xxxxxxxxxxxxxxx> wrote: > >> Now in the 3.0 kernel I know mmc_wait_for_req() has changed and the goal was >> to try and make that function a bit more non-blocking, > > What has been done by Per Förlin is to add pre_req/post_req hooks > for the datapath. This will improve data transfers in general if and > only if the driver can do some meaningful work in these hooks, so > your driver needs to be patched to use these. > > Per patched a few select drivers to prepare the DMA buffers > at this time. In our case (mmci.c) dma_map_sg() can be done in > parallel with an ongoing transfer. > > In our case (ux500, mmci, dma40) we don't have bounce buffers > so the only thing that will happen in parallel with ongoing transfers > is L2 and L1 cache flush. *still* we see a noticeable improvement in > throughput, most in L2, but even on the U300 which only does L1 > cache I see some small improvements. > > I *guess* if you're using bounce buffers, the gain will be even > more pronounced. > > (Per, correct me if I'm wrong on any of this...) > Summary: * The mmc block driver runs mmc_blk_rw_rq_prep(), mmc_queue_bounce_post() and __blk_end_request() in parallel with an ongoing mmc transfer. * The driver may use the hooks to schedule low level work such as preparing dma and caches in parallel with ongoing mmc transfer. * The big benefit of this is when using DMA and running the CPU at a lower speed. Here's an example of that: https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req#Block_device_tests_with_governor >> with it too much because my current focus is on existing products and no >> handheld product uses a 3.0 kernel yet (that I am aware of at least). >> However, I still see the fundamental problem is that the MMC stack, which >> was probably written with the intended purpose to be independent of the OS >> block subsystem (struct request and other stuff), really isn't independent >> of the OS block subsystem and will cause holdups between one another, >> thereby dragging down read/write performance of the MMC. > > There are two issues IIRC: > > - The block layer does not provide enough buffers at a time for > the out-of-order buffer pre/post preps to make effect, I think this > was during writes only (Per, can you elaborate?) > Writes are buffered and pushed down many in one go. This mean they can easily be scheduled to be prepared while another is being transferred. Large continues reads are pushed down to MMC synchronously one request per read ahead size. The next large continues read will wait in the block layer and not start until the current one is complete. Read more about the details here: https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req#Analysis_of_how_block_layer_adds_read_request_to_the_mmc_block_queue > - Anything related to card geometries and special sectors and > sector sizes etc, i.e. the stuff that Arnd has analyzed in detail, > also Tixy looked into that for some cards IIRC. > > Each needs to be adressed and is currently "to be done". > >> The other fundamental problem is the writes themselves. Way, WAY more >> writes occur on a handheld system in an end-user's hands than reads. >> Fundamental computer principle states "you make the common case fast". So >> focus should be on how to complete a write operation the fastest way >> possible. > > First case above I think, yep it needs looking into... > The mmc non-blocking patches only tries to move any overhead in parallel with transfer. The actual transfer speed of MMC reads and writes are unaffected. I am hoping that the eMMC v4.5 packed commands support (the ability to group a series of commands in a single data transaction) will help to boost the performance in the future. Regards, Per -- 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
