xxhash ?

Joakim Tjernlund Joakim.Tjernlund at infinera.com
Thu Dec 28 02:52:25 PST 2017


On Thu, 2017-12-28 at 11:06 +0100, Richard Weinberger wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> Am Donnerstag, 28. Dezember 2017, 10:44:05 CET schrieb Joakim Tjernlund:
> > On Thu, 2017-12-28 at 10:38 +0100, Richard Weinberger wrote:
> > 
> > > CAUTION: This email originated from outside of the organization. Do not
> > > click links or open attachments unless you recognize the sender and know
> > > the content is safe.
> > > 
> > > Joakim,
> > > 
> > > On Thu, Dec 28, 2017 at 7:13 AM, Joakim Tjernlund
> > > <Joakim.Tjernlund at infinera.com> wrote:
> > > 
> > > > Now that xxhash is in the tree one could look at replacing
> > > > crc32 in JFFS2/UBI. This would make checksumming much faster.
> > > 
> > > 
> > > Since this will require a change of the on-disk format we have to be
> > > very careful.
> > > Do you have a use-case where crc32 is the bottle neck?
> > 
> > 
> > Not directly, I remember the good old days when mounting took forever,
> > mostly
> 
>  due to crc32. I then optimized crc32(the big tables you have today)
> > and some other JFFS2 optimizations. Since crc32 is used everywhere in JFFS2
> > I figure xxhash would help, especially on low end CPUs
> 
> Unless this gives a decent speedup I don't think we should add new features to
> JFFS2.

xxhash could be worth it but someone will have to test it first

> For UBI/UBIFS it is a different story. Did you also tests with UBI?

Na, this was long before UBI existed :)


More information about the linux-mtd mailing list