Re: slow eMMC write speed

[J Freyensee <james_p_freyensee@linux.intel.com>]

On 10/03/2011 01:19 PM, Andrei Warkentin wrote:
> Hi James,
>
> ----- Original Message -----
>> From: "J Freyensee"<james_p_freyensee@linux.intel.com>
>>
>> Yeah, I know I'd be doing myself a huge favor by working off of
>> mmc-next
>> (or close to it), but product-wise, my department doesn't care for
>> sustaining current platforms...yet (still trying to convince).
>>
>
> I'd suggest working on linux-mmc. You can always back-port.
>
>> So I was looking into sticking a write cache into block.c driver as a
>> parameter, so it can be turned on and off upon driver load.  Any
>> write
>> operation goes to the cache and only on a cache collision will the
>> write operation get sent to the host controller for a write.  What I
>> have working so far is just with an MMC card in an MMC slot of a
>> laptop,
>> and just bare-bones.  No general flush routine, error-handling, etc.
>>   From a couple performance measurements I did on the MMC slot using
>> blktrace/blkparse and 400MB write transactions, I was seeing huge
>> performance boost with no data corruption.  So it is not looking like
>> a
>> total hair-brained idea.  But I am still pretty far from
>> understanding
>> everything here.  And the real payoff we want to see is performance a
>> user can see on a handheld (i.e., Android) systems.
>>
>
> Interesting. Thanks for sharing. I don't want to seem silly, but how is what you're doing different from
> the page cache? The page cache certainly defers write back (and I believe this is tunable...I'm not too
> familiar yet or comfortable around the rest of blk I/O and VM).

The idea is the page cache is too generic for hand-held (i.e. Android) 
workloads.  Page cache handles regular files, directories, 
user-swappable processes, etc, and all of that has to contend with the 
resource available for the page cache.  This is specific to eMMC 
workloads.  Namely, for games and even .pdf files on an Android system 
(ARM or Intel), there are a lot of 1-2 sector writes and almost 0 reads.

But by no means am I an expert on the page cache area either.

You are certainly right that the page cache is tunable.  I briefly 
looked at this, but then I decided I need to start writing something to 
start understanding stuff.

What are your test workloads?

For the MMC tests I conducted, they were just write blasts, like writing 
200 1MB files 200 times.  I just did enough as a 'thumb' test to see if 
it's worth killing myself on an Android box...it's a little more 
challenging getting it to work on an Android system since block.c is 
*THE* driver, whereas an MMC slot on a laptop is like some peon 
extension the laptop doesn't need.

I would
> guess this wouldn't have too great of an impact on a non O_DIRECT access, and O_DIRECT access anyway have
> to bypass any caching logic.

You are correct; I've already discovered I'd need to bypass the cache on 
O_DIRECT access.

>
> A


-- 
J (James/Jay) Freyensee
Storage Technology Group
Intel Corporation