* [U-Boot] [PATCHv2] block: Have BLOCK_CACHE default to y in some cases
@ 2018-05-22 16:24 Tom Rini
2018-06-08 11:19 ` [U-Boot] [U-Boot, PATCHv2] " Tom Rini
2018-06-08 15:30 ` [U-Boot] [PATCHv2] " Adam Ford
0 siblings, 2 replies; 6+ messages in thread
From: Tom Rini @ 2018-05-22 16:24 UTC (permalink / raw
To: u-boot
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
--
2.7.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [U-Boot] [U-Boot, PATCHv2] block: Have BLOCK_CACHE default to y in some cases
2018-05-22 16:24 [U-Boot] [PATCHv2] block: Have BLOCK_CACHE default to y in some cases Tom Rini
@ 2018-06-08 11:19 ` Tom Rini
2018-06-08 15:30 ` [U-Boot] [PATCHv2] " Adam Ford
1 sibling, 0 replies; 6+ messages in thread
From: Tom Rini @ 2018-06-08 11:19 UTC (permalink / raw
To: u-boot
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!
--
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/20180608/f3f1f047/attachment.sig>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [PATCHv2] block: Have BLOCK_CACHE default to y in some cases
2018-05-22 16:24 [U-Boot] [PATCHv2] block: Have BLOCK_CACHE default to y in some cases Tom Rini
2018-06-08 11:19 ` [U-Boot] [U-Boot, PATCHv2] " Tom Rini
@ 2018-06-08 15:30 ` Adam Ford
2018-06-08 19:15 ` Tom Rini
1 sibling, 1 reply; 6+ messages in thread
From: Adam Ford @ 2018-06-08 15:30 UTC (permalink / raw
To: u-boot
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 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
> --
> 2.7.4
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [PATCHv2] block: Have BLOCK_CACHE default to y in some cases
2018-06-08 15:30 ` [U-Boot] [PATCHv2] " Adam Ford
@ 2018-06-08 19:15 ` Tom Rini
2018-06-08 20:20 ` Adam Ford
0 siblings, 1 reply; 6+ messages in thread
From: Tom Rini @ 2018-06-08 19:15 UTC (permalink / raw
To: 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!
--
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/20180608/857880ed/attachment.sig>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [PATCHv2] block: Have BLOCK_CACHE default to y in some cases
2018-06-08 19:15 ` Tom Rini
@ 2018-06-08 20:20 ` Adam Ford
2018-06-08 20:49 ` Adam Ford
0 siblings, 1 reply; 6+ messages in thread
From: Adam Ford @ 2018-06-08 20:20 UTC (permalink / raw
To: u-boot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [PATCHv2] block: Have BLOCK_CACHE default to y in some cases
2018-06-08 20:20 ` Adam Ford
@ 2018-06-08 20:49 ` Adam Ford
0 siblings, 0 replies; 6+ messages in thread
From: Adam Ford @ 2018-06-08 20:49 UTC (permalink / raw
To: u-boot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-06-08 20:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-05-22 16:24 [U-Boot] [PATCHv2] block: Have BLOCK_CACHE default to y in some cases Tom Rini
2018-06-08 11:19 ` [U-Boot] [U-Boot, PATCHv2] " Tom Rini
2018-06-08 15:30 ` [U-Boot] [PATCHv2] " Adam Ford
2018-06-08 19:15 ` Tom Rini
2018-06-08 20:20 ` Adam Ford
2018-06-08 20:49 ` Adam Ford
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.