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