Hi James, ----- Original Message ----- > From: "J Freyensee" <james_p_freyensee@xxxxxxxxxxxxxxx> > > 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). What are your test workloads? 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. A -- 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
