drivers: block: Allow to cache 4K blocks by default
PATCH 1/1 drivers: block: Allow to cache 4K blocks by default
The default settings of the block cache so far only allow to hold single 1K blocks. However, larger filesystems tend to use 4K. Failing to cache those massively degrades access performance unless you manually tune the cache first. This is not desirable.
---
My "load mmc is slow" problem reappeared on AM65xx after growing the rootfs to almost 1 GB - despite an active block cache.
drivers/block/blkcache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/block/blkcache.c +1 -1
@@ -24,7 +24,7 @@ struct block_cache_node {static LIST_HEAD (block_cache);static struct block_cache_stats _stats = { - .max_blocks_per_entry =2 , + .max_blocks_per_entry =8 , .max_entries =32 };
Signature · 1 line
2.16.4
PATCH 1/1 drivers: block: Allow to cache 4K blocks by default
Quoted 6 lines · Jan Kiszka
The default settings of the block cache so far only allow to hold single 1K blocks. However, larger filesystems tend to use 4K. Failing to cache those massively degrades access performance unless you manually tune the cache first. This is not desirable.
Signed-off-by Jan Kiszka <[email protected]>
I submitted the same patch before [1], oddly enough it was not picked by Tom.
[1]
http://u-boot.10912.n7.nabble.com/PATCH-RFC-blk-Increase-cache-element-size-td337975.html
Quoted 22 lines
---
My "load mmc is slow" problem reappeared on AM65xx after growing the rootfs to almost 1 GB - despite an active block cache.
drivers/block/blkcache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/block/blkcache.c +1
-1@@ -24,7 +24,7 @@ struct block_cache_node {static LIST_HEAD (block_cache);static struct block_cache_stats _stats = { - .max_blocks_per_entry =2 , + .max_blocks_per_entry =8 , .max_entries =32 };
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 drivers: block: Allow to cache 4K blocks by default
Quoted 10 lines · Marek Vasut
Quoted 6 lines · Jan Kiszka
The default settings of the block cache so far only allow to hold single 1K blocks. However, larger filesystems tend to use 4K. Failing to cache those massively degrades access performance unless you manually tune the cache first. This is not desirable.
Signed-off-by Jan Kiszka <[email protected]>I submitted the same patch before [1], oddly enough it was not picked by Tom.
Maybe because the follow-up discussion felt like the topic didn't settle? I would vote for resolving this 4K think first, because it's very real. OTW: You patch should go in first of all, then better solutions can be developed on top.
Jan
Quoted 28 lines
[1]
http://u-boot.10912.n7.nabble.com/PATCH-RFC-blk-Increase-cache-element-size-td337975.htmlQuoted 22 lines
---
My "load mmc is slow" problem reappeared on AM65xx after growing the rootfs to almost 1 GB - despite an active block cache.
drivers/block/blkcache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/block/blkcache.c +1
-1@@ -24,7 +24,7 @@ struct block_cache_node {static LIST_HEAD (block_cache);static struct block_cache_stats _stats = { - .max_blocks_per_entry =2 , + .max_blocks_per_entry =8 , .max_entries =32 };
Signature · 2 lines
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
PATCH 1/1 drivers: block: Allow to cache 4K blocks by default
In reply to Marek VasutQuoted 6 lines · Marek Vasut
Quoted 5 lines · Jan Kiszka
The default settings of the block cache so far only allow to hold single 1K blocks. However, larger filesystems tend to use 4K. Failing to cache those massively degrades access performance unless you manually tune the cache first. This is not desirable.
Quoted 7 lines
Quoted 1 line
Signed-off-by Jan Kiszka <[email protected]>I submitted the same patch before [1], oddly enough it was not picked by Tom.
[1]
http://u-boot.10912.n7.nabble.com/PATCH-RFC-blk-Increase-cache-element-size-td337975.html
Based on a quick re-read, I had filed that patch as "Marek says he'll look into a more complex but general scheme". If that's not the case then yes, we can just do that. Thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181210/e6a3af73/attachment.sig>
PATCH 1/1 drivers: block: Allow to cache 4K blocks by default
Quoted 12 lines · Tom Rini
Quoted 11 lines · Marek Vasut
Quoted 6 lines · Jan Kiszka
The default settings of the block cache so far only allow to hold single 1K blocks. However, larger filesystems tend to use 4K. Failing to cache those massively degrades access performance unless you manually tune the cache first. This is not desirable.
Signed-off-by Jan Kiszka <[email protected]>I submitted the same patch before [1], oddly enough it was not picked by Tom.
Quoted 6 lines
Quoted 2 lines
[1]
http://u-boot.10912.n7.nabble.com/PATCH-RFC-blk-Increase-cache-element-size-td337975.htmlBased on a quick re-read, I had filed that patch as "Marek says he'll look into a more complex but general scheme". If that's not the case then yes, we can just do that. Thanks!
I still don't see the original patch in u-boot/master
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 drivers: block: Allow to cache 4K blocks by default
Quoted 13 lines · Marek Vasut
Quoted 12 lines · Tom Rini
Quoted 11 lines · Marek Vasut
Quoted 6 lines · Jan Kiszka
The default settings of the block cache so far only allow to hold single 1K blocks. However, larger filesystems tend to use 4K. Failing to cache those massively degrades access performance unless you manually tune the cache first. This is not desirable.
Signed-off-by Jan Kiszka <[email protected]>I submitted the same patch before [1], oddly enough it was not picked by Tom.
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
[1]
http://u-boot.10912.n7.nabble.com/PATCH-RFC-blk-Increase-cache-element-size-td337975.htmlBased on a quick re-read, I had filed that patch as "Marek says he'll look into a more complex but general scheme". If that's not the case then yes, we can just do that. Thanks!
I still don't see the original patch in u-boot/master
Ping. Some form of this change should go into the next release, IMHO.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
PATCH 1/1 drivers: block: Allow to cache 4K blocks by default
Quoted 17 lines · Jan Kiszka
Quoted 16 lines · Marek Vasut
Quoted 15 lines · Tom Rini
Quoted 13 lines · Marek Vasut
Quoted 6 lines · Jan Kiszka
The default settings of the block cache so far only allow to hold single 1K blocks. However, larger filesystems tend to use 4K. Failing to cache those massively degrades access performance unless you manually tune the cache first. This is not desirable.
Signed-off-by Jan Kiszka <[email protected]>I submitted the same patch before [1], oddly enough it was not picked by Tom.
[1]
http://u-boot.10912.n7.nabble.com/PATCH-RFC-blk-Increase-cache-element-size-td337975.html
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Based on a quick re-read, I had filed that patch as "Marek says he'll look into a more complex but general scheme". If that's not the case then yes, we can just do that. Thanks!
I still don't see the original patch in u-boot/master
Ping. Some form of this change should go into the next release, IMHO.
So, this initially tripped over some EFI related issue, which has been fixed. But at this point I'm going to pull it in from v2019.04 instead.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190103/69436cf4/attachment.sig>