On Mon, 29 Oct 2018 13:27:36 +0100 Vitaly Wool <vitalywool@xxxxxxxxx> wrote: > Hi Andrew, > > Den tors 25 okt. 2018 kl 21:42 skrev Andrew Morton < > akpm@xxxxxxxxxxxxxxxxxxxx>: > > > On Thu, 25 Oct 2018 11:28:21 +0200 Vitaly Wool <vitalywool@xxxxxxxxx> > > wrote: > > > > > Reclaim and free can race on an object (which is basically ok) but > > > in order for reclaim to be able to map "freed" object we need to > > > encode object length in the handle. handle_to_chunks() is thus > > > introduced to extract object length from a handle and use it during > > > mapping of the last object we couldn't correctly map before. > > > > What are the runtime effects of this change? > > > > I haven't observed any adverse impact with this change used in zswap (and > in fact, this is a bugfix for zswap operation). There is a slight under 1% > impact when z3fold is used with ZRAM but since the support for ZRAM over > zpool is still out of tree, I take it doesn't matter at this point, right? > I mean "runtime effects", not "run time effects" ;) Apart from wishing to document this change fully, I'm trying to understand which kernel version(s) need the fix. To understand that, I need to know the effect upon end-user-visible behaviour. You say it fixes a bug - please describe that bug: how it is triggered, what effect is has, etc. Also, any suggestions as to which kernel versions we should fix is always welcome.
