Hi Stephen,
On 03/17/2016 02:23 PM, Stephen Warren wrote:
On 03/16/2016 03:40 PM, Eric Nelson wrote:
Signed-off-by: Eric Nelson eric@nelint.com
Patch description.
drivers/mmc/mmc.c | 10 +++++++++- drivers/mmc/mmc_write.c | 7 +++++++
Presumably it makes sense for the cache to work for IDE, SATA, USB, SCSI, ... too. I wonder if it's possible to put this code somewhere more central than mmc*.c so it automatically applies to dev_desc->block_read() (see include/part.h). Perhaps not since each implementation supplies its own block_read function directly, so the cache calls do need to be duplicated everywhere.
Yeah. I haven't found a spot that would allow interception of the various block_read/write functions.
The get_dev_hwpart() routine in disk/part.c is close, but it seems to be bypassed by cmd_mmc, cmd_sata, et cetera.
I think the best that can be done is to provide a common shim that can easily be inserted from within the various block driver code.
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
- SPDX-License-Identifier: GPL-2.0+
*/
- #include <config.h>
Nit: unrelated change.
I think there is a missing call to cache_block_invalidate() when the MMC device gets re-enumerated/re-initialized. The user would do something to trigger this (e.g. mmc rescan) when they'd swapped an SD card out for example.
Good catch.
Do you have any stats on how many operations this saves for typical FS operations such as:
- Partition table type identification (with various types such as
MBR/DOS, GPT, ...)
- Partition enumeration
- Filesystem identification (with various filesystems such as FAT, ext,
...)
- File reads
Not yet, but I'm working something up that will allow this to be gathered easily. As soon as we implement a cache, it provides a nice spot for tracing operations.
Regards,
Eric