From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Lawnick Date: Tue, 14 Oct 2008 11:25:22 +0200 Subject: [U-Boot] [PATCH] jffs2: cache data_crc results In-Reply-To: <1223877234-720-7-git-send-email-yanok@emcraft.com> References: <1223877234-720-1-git-send-email-yanok@emcraft.com> <1223877234-720-7-git-send-email-yanok@emcraft.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Ilya Yanok said the following: > As we moved data_crc() invocation from jffs2_1pass_build_lists() to > jffs2_1pass_read_inode() data_crc is going to be calculated on each > inode access. This patch adds caching of data_crc() results. There > is no significant improvement in speed (because of flash access > caching added in previous patch I think, crc in RAM is really fast) > but this patch impacts memory usage -- every b_node structure uses > 12 bytes instead of 8. > > Signed-off-by: Alexey Neyman > Signed-off-by: Ilya Yanok > --- > fs/jffs2/jffs2_1pass.c | 5 ++++- > fs/jffs2/jffs2_private.h | 1 + > 2 files changed, 5 insertions(+), 1 deletions(-) > > diff --git a/fs/jffs2/jffs2_1pass.c b/fs/jffs2/jffs2_1pass.c > index 9d9ac1a..b41c299 100644 > --- a/fs/jffs2/jffs2_1pass.c > +++ b/fs/jffs2/jffs2_1pass.c > @@ -768,7 +768,10 @@ jffs2_1pass_read_inode(struct b_lists *pL, u32 inode, char *dest) > put_fl_mem(jNode, pL->readbuf); > continue; > } > - if (!data_crc(jNode)) { > + if (b->datacrc == CRC_UNKNOWN) > + b->datacrc = data_crc(jNode) ? > + CRC_OK : CRC_BAD; > + if (b->datacrc == CRC_BAD) { > put_fl_mem(jNode, pL->readbuf); > continue; > } > diff --git a/fs/jffs2/jffs2_private.h b/fs/jffs2/jffs2_private.h > index b3fab1c..7a9eda6 100644 > --- a/fs/jffs2/jffs2_private.h > +++ b/fs/jffs2/jffs2_private.h > @@ -7,6 +7,7 @@ > struct b_node { > u32 offset; > struct b_node *next; > + enum { CRC_UNKNOWN = 0, CRC_OK, CRC_BAD } datacrc; > }; > > struct b_list { Could be so kind to give us your source reference? I can't find above code in u-boot 1.3.3 nor 1.3.4 The same seems to apply to the other patches you've sent yesterday :-( I'm eagerly waiting for summary patch ;-) Regards, Michael