On 2/6/24 8:14 PM, Sergey Senozhatsky wrote: > On (24/02/06 19:40), Jens Axboe wrote: >> On 2/6/24 6:44 PM, Sergey Senozhatsky wrote: >>> On (24/02/07 09:25), Barry Song wrote: >>>> From: Barry Song <v-songbaohua@xxxxxxxx> >>>> >>>> Firstly, there is no need to keep zcomp_strm's buffers contiguous >>>> physically. >>>> >>>> Secondly, The recent mTHP project has provided the possibility to >>>> swapout and swapin large folios. Compressing/decompressing large >>>> blocks can hugely decrease CPU consumption and improve compression >>>> ratio. This requires us to make zRAM support the compression and >>>> decompression for large objects. >>>> With the support of large objects in zRAM of our out-of-tree code, >>>> we have observed many allocation failures during CPU hotplug as >>>> large objects need larger buffers. So this change is also more >>>> future-proof once we begin to bring up multiple sizes in zRAM. >>>> >>>> Signed-off-by: Barry Song <v-songbaohua@xxxxxxxx> >>> >>> Reviewed-by: Sergey Senozhatsky <senozhatsky@xxxxxxxxxxxx> >>> >>> Note: >>> Taking it in NOT because of the out-of-tree code (we don't really >>> do that), but because this is executed from CPU offline/online >>> paths, which can happen on devices with fragmented memory (a valid >>> concern IMHO). >>> >>> Minchan, if you have any objections, please chime in. >> >> Not Minchan, but I do have an issue with the title of the commit, it >> doesn't make any sense. Can the maintainer please re-write that to be >> something that is appropriate and actually describes what the patch >> does? > > Thanks Jens. I fully agree, I requested a better commit message in > v1 feedback, we probably still can improve on this. > > > Something like this? > > --- > > zram: do not allocate physically contiguous strm buffers > > Currently zram allocates 2 physically contigous pages per-CPU's > compression stream (we may have up to 3 streams per-CPU). Since > those buffers are per-CPU we allocate them from CPU hotplug path, > which may have higher risks of failed allocations on devices with > fragmented memory. > > Switch to virtually contiguos allocations - crypto comp does not > seem impose requirements on compression working buffers to be > physically contiguous. Yep, this is much better! Thanks. -- Jens Axboe