[U-Boot] [PATCHv2] block: Have BLOCK_CACHE default to y in some cases
When dealing with filesystems that come from block devices we can get a noticeable performance gain in some use cases from having the block cache enabled. The code paths are valid in other cases when we have BLK set and may provide wins in raw reads in some use cases, so have this be default when BLK is enabled.
Signed-off-by: Tom Rini trini@konsulko.com --- Changes in v2: - Make this default y, unconditionally but depend on BLK which is required for the functionality to be used. --- drivers/block/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index 15fd1bcb2b7e..0792373cfc48 100644 --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -29,7 +29,8 @@ config SPL_BLK
config BLOCK_CACHE bool "Use block device cache" - default n + depends on BLK + default y help This option enables a disk-block cache for all block devices. This is most useful when accessing filesystems under U-Boot since
On Tue, May 22, 2018 at 12:24:16PM -0400, Tom Rini wrote:
When dealing with filesystems that come from block devices we can get a noticeable performance gain in some use cases from having the block cache enabled. The code paths are valid in other cases when we have BLK set and may provide wins in raw reads in some use cases, so have this be default when BLK is enabled.
Signed-off-by: Tom Rini trini@konsulko.com
Applied to u-boot/master, thanks!
On Tue, May 22, 2018 at 11:24 AM Tom Rini trini@konsulko.com wrote:
When dealing with filesystems that come from block devices we can get a noticeable performance gain in some use cases from having the block cache enabled. The code paths are valid in other cases when we have BLK set and may provide wins in raw reads in some use cases, so have this be default when BLK is enabled.
Tony,
This breaks the AM3517 EVM. It appears to cause issues in MLO which may not have enough RAM to cache, but I can fix it by disabling BLOCK_CACHE. I can submit a patch to disable it on the AM3517, but I am wondering if something can/should be done to disable it or optionally disable it in SPL so it's still available in U-Boot. I can confirm that when disabled in SPL only, it works.
Any opinions on this?
adam
Signed-off-by: Tom Rini trini@konsulko.com
Changes in v2:
- Make this default y, unconditionally but depend on BLK which is required for the functionality to be used.
drivers/block/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index 15fd1bcb2b7e..0792373cfc48 100644 --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -29,7 +29,8 @@ config SPL_BLK
config BLOCK_CACHE bool "Use block device cache"
default n
depends on BLKdefault y help This option enables a disk-block cache for all block devices. This is most useful when accessing filesystems under U-Boot since-- 2.7.4
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On Fri, Jun 08, 2018 at 10:30:36AM -0500, Adam Ford wrote:
On Tue, May 22, 2018 at 11:24 AM Tom Rini trini@konsulko.com wrote:
When dealing with filesystems that come from block devices we can get a noticeable performance gain in some use cases from having the block cache enabled. The code paths are valid in other cases when we have BLK set and may provide wins in raw reads in some use cases, so have this be default when BLK is enabled.
Tony,
This breaks the AM3517 EVM. It appears to cause issues in MLO which may not have enough RAM to cache, but I can fix it by disabling BLOCK_CACHE. I can submit a patch to disable it on the AM3517, but I am wondering if something can/should be done to disable it or optionally disable it in SPL so it's still available in U-Boot. I can confirm that when disabled in SPL only, it works.
Any opinions on this?
So, we had talked before about bumping SYS_MALLOC_F_LEN to 0x2000 for ARCH_OMAP2PLUS, but I see am3517 is already doing that. Can you see if there's enough room to go to say 0x4000 and it works? Otherwise, we need to (and I was worried we might) need to add SPL_BLOCK_CACHE and have that default off. Thanks!
On Fri, Jun 8, 2018 at 2:15 PM Tom Rini trini@konsulko.com wrote:
On Fri, Jun 08, 2018 at 10:30:36AM -0500, Adam Ford wrote:
On Tue, May 22, 2018 at 11:24 AM Tom Rini trini@konsulko.com wrote:
When dealing with filesystems that come from block devices we can get a noticeable performance gain in some use cases from having the block cache enabled. The code paths are valid in other cases when we have BLK set and may provide wins in raw reads in some use cases, so have this be default when BLK is enabled.
Tony,
This breaks the AM3517 EVM. It appears to cause issues in MLO which may not have enough RAM to cache, but I can fix it by disabling BLOCK_CACHE. I can submit a patch to disable it on the AM3517, but I am wondering if something can/should be done to disable it or optionally disable it in SPL so it's still available in U-Boot. I can confirm that when disabled in SPL only, it works.
Any opinions on this?
So, we had talked before about bumping SYS_MALLOC_F_LEN to 0x2000 for ARCH_OMAP2PLUS, but I see am3517 is already doing that. Can you see if there's enough room to go to say 0x4000 and it works? Otherwise, we
I tried setting it to 0x4000, but it just hangs:
U-Boot SPL 2018.07-rc1-00040-g71002b508a (Jun 08 2018 - 15:16:44 -0500) Trying to boot from MMC1
need to (and I was worried we might) need to add SPL_BLOCK_CACHE and have that default off. Thanks!
Do you want me to work on that patch or did you want to do it?
adam
-- Tom
On Fri, Jun 8, 2018 at 3:20 PM Adam Ford aford173@gmail.com wrote:
On Fri, Jun 8, 2018 at 2:15 PM Tom Rini trini@konsulko.com wrote:
On Fri, Jun 08, 2018 at 10:30:36AM -0500, Adam Ford wrote:
On Tue, May 22, 2018 at 11:24 AM Tom Rini trini@konsulko.com wrote:
When dealing with filesystems that come from block devices we can get a noticeable performance gain in some use cases from having the block cache enabled. The code paths are valid in other cases when we have BLK set and may provide wins in raw reads in some use cases, so have this be default when BLK is enabled.
Tony,
This breaks the AM3517 EVM. It appears to cause issues in MLO which may not have enough RAM to cache, but I can fix it by disabling BLOCK_CACHE. I can submit a patch to disable it on the AM3517, but I am wondering if something can/should be done to disable it or optionally disable it in SPL so it's still available in U-Boot. I can confirm that when disabled in SPL only, it works.
Any opinions on this?
So, we had talked before about bumping SYS_MALLOC_F_LEN to 0x2000 for ARCH_OMAP2PLUS, but I see am3517 is already doing that. Can you see if there's enough room to go to say 0x4000 and it works? Otherwise, we
I tried setting it to 0x4000, but it just hangs:
U-Boot SPL 2018.07-rc1-00040-g71002b508a (Jun 08 2018 - 15:16:44 -0500) Trying to boot from MMC1
need to (and I was worried we might) need to add SPL_BLOCK_CACHE and have that default off. Thanks!
Do you want me to work on that patch or did you want to do it?
I just submitted a patch to the mailing list which fixes the AM3517. I figured I was 1/2 way there, so I just finished it.
adam
adam
-- Tom
participants (2)
-
Adam Ford -
Tom Rini