[U-Boot] [PATCH v2 5/5] fastboot: sparse: improve CHUNK_TYPE_FILL write performance

[Maxime Ripard <maxime.ripard@free-electrons.com>]

On Thu, Jun 16, 2016 at 10:34:37AM -0700, Steve Rae wrote:
> On Wed, Jun 15, 2016 at 1:36 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Tue, Jun 07, 2016 at 11:19:39AM -0700, Steve Rae wrote:
> >> - increase the size of the fill buffer
> >> - testing has shown a 10x improvement when the sparse image
> >>   has large CHUNK_TYPE_FILL chunks
> >>
> >> Signed-off-by: Steve Rae <srae@broadcom.com>
> >> ---
> >>
> >> Changes in v2: None
> >>
> >>  common/image-sparse.c | 37 +++++++++++++++++++++++++++----------
> >>  1 file changed, 27 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/common/image-sparse.c b/common/image-sparse.c
> >> index 9632c6f..ddf5772 100644
> >> --- a/common/image-sparse.c
> >> +++ b/common/image-sparse.c
> >> @@ -1,4 +1,3 @@
> >> -
> >>  /*
> >>   * Copyright (c) 2009, Google Inc.
> >>   * All rights reserved.
> >> @@ -46,6 +45,10 @@
> >>
> >>  #include <linux/math64.h>
> >>
> >> +#ifndef CONFIG_FASTBOOT_FLASH_FILLBUF_SIZE
> >> +#define CONFIG_FASTBOOT_FLASH_FILLBUF_SIZE (1024 * 512)
> >
> > I wonder whether that would be better to just put the number of blocks
> > there.
> 
> I wanted to imply that this is not just a random value (even though
> the code does values which are not a multiple of the  info->blksz)

I know, but what I was saying is that NAND block size are usually a
couple of kilobytes, while the benefit here probably comes from the
number of blocks, not the actual size they take, which, for the same
benefits, will probably be the same number of blocks, but implies a
bigger size.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20160622/2779844c/attachment.sig>