On (04/19/17 16:22), Minchan Kim wrote: > > > And this bad compress ratio path would be rare, too. > > > > "bad compression" is not uncommon. I wish it was, but it's not. we can't > > really guarantee/expect anything, it's up to compression algorithm and data. > > True. Thanks for the testing! > What are your workloads? on that particular box -- compilation. text + binary files. we swap out pages with random binary data, basically, so I wouldn't expect "bad compression" to be uncommon on embedded devices. > I think user shouldn't use zram for such lots of bad compression workload > if it isn't temporal :). haha may be. p.s. may be there is nothing to fix in upstream and it was a false alarm from my side. it's probably logical to expect that arch that bothered to provide well optimized copy_page() also provides 'equally' optimized memcpy(). if so, then we should be fine. sorry for the noise. -ss