On 03/21/2016 02:45 AM, Eric Nelson wrote:
Here's a more full-featured implementation of a cache for block devices that uses a small linked list of cache blocks.
Why do you use linked list ? You have four entries, you can as well use fixed array. Maybe you should implement an adaptive cache would would use the unpopulated malloc area and hash the sector number(s) into that area ?
Experimentation loading a 4.5 MiB kernel from the root directory of a FAT filesystem shows that a single cache entry of a single block is the only
only ... what ? This is where things started to be interesting, but you leave us hanging :)
Loading the same from the /boot directory of an ext4 filesystem shows a benefit with 4 cache entries, though the single biggest benefit is also with the first cache entry:
=> for n in 0 1 2 4 8 ; do
blkc 1 $n ; blkc c ; blkc i ; load mmc 0:2 10008000 /boot/zImage ; done
changed to max of 0 entries of 1 blocks each 4955304 bytes read in 503 ms (9.4 MiB/s) changed to max of 1 entries of 1 blocks each 4955304 bytes read in 284 ms (16.6 MiB/s) changed to max of 2 entries of 1 blocks each 4955304 bytes read in 284 ms (16.6 MiB/s) changed to max of 4 entries of 1 blocks each 4955304 bytes read in 255 ms (18.5 MiB/s) changed to max of 8 entries of 1 blocks each 4955304 bytes read in 255 ms (18.5 MiB/s)
As mentioned earlier in this thread, the modification to the mmc layer should probably be simpler and easier to apply to other block subsystems.
Eric Nelson (3): drivers: block: add block device cache block: add Kconfig options for BLOCK_CACHE, CMD_BLOCK_CACHE mmc: add support for block device cache
drivers/block/Kconfig | 19 ++++ drivers/block/Makefile | 1 + drivers/block/cache_block.c | 240 ++++++++++++++++++++++++++++++++++++++++++++ drivers/mmc/mmc.c | 10 +- drivers/mmc/mmc_write.c | 7 ++ include/part.h | 69 +++++++++++++ 6 files changed, 345 insertions(+), 1 deletion(-) create mode 100644 drivers/block/cache_block.c