On Fri, Dec 04, 2020 at 10:38:08AM +0800, Chao Yu wrote: > On 2020/12/4 10:06, Gao Xiang wrote: > > On Fri, Dec 04, 2020 at 09:56:27AM +0800, Chao Yu wrote:
... > > > > > Keep lz4hc dirty data under writeback could block writeback, make kswapd > > busy, and direct memory reclaim path, I guess that's why rare online > > compression chooses it. My own premature suggestion is that it'd better > > to show the CR or performance benefits in advance, and prevent unprivileged > > users from using high-level lz4hc algorithm (to avoid potential system > > attack.) > > either from mount options or ioctl. > > Yes, I guess you are worry about destop/server scenario, as for android > scenario, > all compression related flow can be customized, and I don't think we will use > online lz4hc compress; for other scenario, except the numbers, I need to add > the > risk of using lz4hc algorithm in document. Yes, I was saying the general scenario. My overall premature thought is that before releasing some brand new algorithm, it may be better to evaluate first it'd benefit to some scenarios first (either on CR or performance side, or why adding this?), or it would might cause lzo-rle likewise situation in the future (and add more dependency to algorithms, you might see BWT-based bzip2 removal patch https://lore.kernel.org/r/20201117223253.65920-1-alex_y...@yahoo.ca (since I personally don't think BWT is a good algorithm as well)... Just FYI ... If i'm wrong, kindly ignore me :) Thanks, Gao Xiang > > Thanks,
