Message ID | 1465323579-18928-6-git-send-email-srae@broadcom.com |
---|---|
State | Accepted |
Delegated to: | Tom Rini |
Headers | show |
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. NAND blocks are much larger than MMC's, so the gain benefit might not be even. Maxime
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) Thanks, Steve > > NAND blocks are much larger than MMC's, so the gain benefit might not > be even. > > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com
On Thu, Jun 16, 2016 at 10:34 AM, Steve Rae <srae@broadcom.com> 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 handle values which are not a multiple of the info->blksz) > Thanks, Steve > >> >> NAND blocks are much larger than MMC's, so the gain benefit might not >> be even. >> >> Maxime >> >> -- >> Maxime Ripard, Free Electrons >> Embedded Linux, Kernel and Android engineering >> http://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
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> Applied to u-boot/master, thanks!
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) +#endif + void write_sparse_image( struct sparse_storage *info, const char *part_name, void *data, unsigned sz) @@ -62,7 +65,11 @@ void write_sparse_image( sparse_header_t *sparse_header; chunk_header_t *chunk_header; uint32_t total_blocks = 0; + int fill_buf_num_blks; int i; + int j; + + fill_buf_num_blks = CONFIG_FASTBOOT_FLASH_FILLBUF_SIZE / info->blksz; /* Read and skip over sparse image header */ sparse_header = (sparse_header_t *)data; @@ -169,8 +176,9 @@ void write_sparse_image( fill_buf = (uint32_t *) memalign(ARCH_DMA_MINALIGN, - ROUNDUP(info->blksz, - ARCH_DMA_MINALIGN)); + ROUNDUP( + info->blksz * fill_buf_num_blks, + ARCH_DMA_MINALIGN)); if (!fill_buf) { fastboot_fail( "Malloc failed for: CHUNK_TYPE_FILL"); @@ -180,7 +188,10 @@ void write_sparse_image( fill_val = *(uint32_t *)data; data = (char *)data + sizeof(uint32_t); - for (i = 0; i < (info->blksz / sizeof(fill_val)); i++) + for (i = 0; + i < (info->blksz * fill_buf_num_blks / + sizeof(fill_val)); + i++) fill_buf[i] = fill_val; if (blk + blkcnt > info->start + info->size) { @@ -192,18 +203,24 @@ void write_sparse_image( return; } - for (i = 0; i < blkcnt; i++) { - blks = info->write(info, blk, 1, fill_buf); - /* blks might be > 1 (eg. NAND bad-blocks) */ - if (blks < 1) { - printf("%s: %s, block # " LBAFU "\n", - __func__, "Write failed", blk); + for (i = 0; i < blkcnt;) { + j = blkcnt - i; + if (j > fill_buf_num_blks) + j = fill_buf_num_blks; + blks = info->write(info, blk, j, fill_buf); + /* blks might be > j (eg. NAND bad-blocks) */ + if (blks < j) { + printf("%s: %s " LBAFU " [%d]\n", + __func__, + "Write failed, block #", + blk, j); fastboot_fail( "flash write failure"); free(fill_buf); return; } blk += blks; + i += j; } bytes_written += blkcnt * info->blksz; total_blocks += chunk_data_sz / sparse_header->blk_sz;
- 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(-)