On Wed, Jun 07, 2023 at 07:51:43PM +0000, Yosry Ahmed wrote: > Commit 71024cb4a0bf ("frontswap: remove frontswap_tmem_exclusive_gets") > removed support for exclusive loads from frontswap as it was not used. > Bring back exclusive loads support to frontswap by adding an "exclusive" > output parameter to frontswap_ops->load. > > On the zswap side, add a module parameter to enable/disable exclusive > loads, and a config option to control the boot default value. > Refactor zswap entry invalidation in zswap_frontswap_invalidate_page() > into zswap_invalidate_entry() to reuse it in zswap_frontswap_load() if > exclusive loads are enabled. > > With exclusive loads, we avoid having two copies of the same page in > memory (compressed & uncompressed) after faulting it in from zswap. On > the other hand, if the page is to be reclaimed again without being > dirtied, it will be re-compressed. Compression is not usually slow, and > a page that was just faulted in is less likely to be reclaimed again > soon. > > Suggested-by: Yu Zhao > Signed-off-by: Yosry Ahmed > --- > > v1 -> v2: > - Add a module parameter to control whether exclusive loads are enabled > or not, the config option now controls the default boot value instead. > Replaced frontswap_ops->exclusive_loads by an output parameter to > frontswap_ops->load() (Johannes Weiner). > --- Hi Yosry, I was testing the latest mm-unstable and encountered a bug. It was bisectable and this is the first bad commit. Attached config file and bisect log. The oops message is available at: https://social.kernel.org/media/eace06d71655b3cc76411366573e4a8ce240ad65b8fd20977d7c73eec9dc2253.jpg (the head commit is b9c91c43412f2e07 "mm: zswap: support exclusive loads") (it's an image because I tested it on real machine) This is what I have as swap space: $ cat /proc/swaps Filename Type Size Used Priority /var/swap file 134217724 0 -2 /dev/zram0 partition 8388604 0 100