On Wed, Sep 28, 2011 at 2:01 PM, J Freyensee <james_p_freyensee@xxxxxxxxxxxxxxx> wrote: > On 09/28/2011 01:34 PM, Praveen G K wrote: >> >> On Wed, Sep 28, 2011 at 12:59 PM, J Freyensee >> <james_p_freyensee@xxxxxxxxxxxxxxx> wrote: >>> >>> On 09/28/2011 12:06 PM, Praveen G K wrote: >>>> >>>> On Tue, Sep 27, 2011 at 10:42 PM, Linus Walleij >>>> <linus.walleij@xxxxxxxxxx> wrote: >>>>> >>>>> On Fri, Sep 23, 2011 at 7:05 AM, Praveen G K<praveen.gk@xxxxxxxxx> >>>>> wrote: >>>>> >>>>>> I am working on the block driver module of the eMMC driver (SDIO 3.0 >>>>>> controller). I am seeing very low write speed for eMMC transfers. On >>>>>> further debugging, I observed that every 63rd and 64th transfer takes >>>>>> a long time. >>>>> >>>>> Are you not just seeing the card-internal garbage collection? >>>>> http://lwn.net/Articles/428584/ >>>> >>>> Does this mean, theoretically, I should be able to achieve larger >>>> speeds if I am not using linux? >>> >>> In theory in a fairy-tale world, maybe, in reality, not really. In R/W >>> performance measurements we have done, eMMC performance in products users >>> would buy falls well, well short of any theoretical numbers. We believe >>> in >>> theory, the eMMC interface should be able to support up to 100MB/s, but >>> in >>> reality on real customer platforms write bandwidths (for example) barely >>> approach 20MB/s, regardless if it's a Microsoft Windows environment or >>> Android (Linux OS environment we care about). So maybe it is software >>> implementation issues of multiple OSs preventing higher eMMC performance >>> numbers (hence the reason why I sometimes ask basic coding questions of >>> the >>> MMC subsystem- the code isn't the easiest to follow); however, one looks >>> no >>> further than what Apple has done with the iPad2 to see that eMMC probably >>> just is not a good solution to use in the first place. We have measured >>> Apple's iPad2 write performance on *WHAT A USER WOULD SEE* being double >>> what >>> we see with products using eMMC solutions. The big difference? Apple >>> doesn't use eMMC at all for the iPad2. >> >> Thanks for all the clarification. The problem is I am seeing write >> speeds of about 5MBps on a Sandisk eMMC product and I can clearly see >> the time lost when measured between sending a command and receiving a >> data irq. I am not sure what kind of an issue this is. 5MBps feels >> really slow but can the internal housekeeping of the card take so much >> time? > > Have you tried to trace through all structs used for an MMC operation??! > Good gravy, there are request, mmc_queue, mmc_card, mmc_host, > mmc_blk_request, mmc_request, multiple mmc_command and multiple scatterlists > that these other structs use...I've been playing around on trying to cache > some things to try and improve performance and it blows me away how many > variables and pointers I have to keep track of for one operation going to an > LBA on an MMC. I keep wondering if more of the 'struct request' could have > been used, and 1/3 of these structures could be eliminated. And another > thing I wonder too is how much of this infrastructure is really needed, that > when I do ask "what is this for?" question on the list and no one responds, > if anyone else understands if it's needed either. I know I am not using the scatterlists, since the scatterlists are aggregated into a 64k bounce buffer. Regarding the different structs, I am just taking them on face value assuming everything works "well". But, my concern is why does it take such a long time (250 ms) to return a transfer complete interrupt on occasional cases. During this time, the kernel is just waiting for the txfer_complete interrupt. That's it. > I mean, for the usual transfers it takes about 3ms to transfer >> >> 64kB of data, but for the 63rd and 64th transfers, it takes 250 ms. >> The thing is this is not on a file system. I am measuring the speed >> using basic "dd" command to write directly to the block device. >> >>> So, is this a software issue? or if >>>> >>>> there is a way to increase the size of bounce buffers to 4MB? >>>> >>> >>> >>> >>>>> 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 >>> >>> >>> -- >>> J (James/Jay) Freyensee >>> Storage Technology Group >>> Intel Corporation >>> >> -- >> 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 > > > -- > J (James/Jay) Freyensee > Storage Technology Group > Intel Corporation > -- 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
