> just a few). It is impossible in it's current state to use less than
> roughly 1MB of memory, even though the algorithm doesn't give that
> restriction at all. Drop that down to 280k, the current zlib value
> and you won't see a difference in compression ratios for jffs2 at
Well, if you drop that down to 280k, and you do not beat zlib
compression by a "comfortable margin", it's just pointless code churn in
addition to swapping out the faster algorithm for the slower algorithm.
If you drop that down to 280k with much better compression than zlib,
that's fantastic and useful, and people won't mind the slower algorithm :)
The issue of memory usage at high compression rates was the main reason
why I didn't push the patch upstream and pursue bzlib further.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/