Hi James, 2011/9/29 J Freyensee <james_p_freyen...@linux.intel.com>: > As I've been playing around with with buffering/caching, it seems to me an > opportunity to simplify things in the MMC space is to eliminate the need for > a mmc_blk_request struct or mmc_request struct. With looking through the > mmc_blk_issue_rw_rq(), there is a lot of work to initialize struct > mmc_blk_request brq, only to pass a struct mmc_queue variable the actual > mmc_wait_for_req() instead. In fact, some of the parameters in the struct > mmc_blk_request member brq.mrq (of type mmc_request) wind up just pointing > to members in struct mmc_blk_request brq. Granted, I totally don't > understand everything going on here and I haven't studied this code nearly > as long as others, but when I see something like this, the first thing that > comes up in my mind is 'elimination/simplification opportunity'.
mmc_request is what is actually handled by the SD/MMC host driver - compact representation of what needs to be done (unneeded fields are NULL pointers). mmc_blk_request is basically the backing store for these fields, for the block driver. I would guess the mmc_request doesn't contain the fields because it would be inefficient (or correct me). And since there is quite a bit of logic behind running the actual MMC commands (esp. w.r.t to mrq->sbc and mrq->stop), it would not be a good idea to get rid of mmc_request and pull the strings from card drivers either. Praveen: As for timings on Toshiba cards, you can search "MMC quirks relating to performance/lifetime." in the archives. There was quite a lot of very interesting data and discussions specifically regarding performance, and it would be pretty impossible and a disservice to try to summarize it :-). In short, I've definitely seen 100ms blips, pronounced by extra GC caused by unaligned accesses across allocation units (if I remember correctly). You could try and reduce the worst case, but it would make the average case worse. It's a bit of voodoo. Best solution is interact with your vendor and get suggestions on use and errata. 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
