Re: [PATCH mm-unstable v1] mm/truncate: batch-clear shadow entries

[Andrew Morton <akpm@linux-foundation.org>]

On Mon,  8 Jul 2024 15:27:53 -0600 Yu Zhao <yuzhao@google.com> wrote:

> Make clear_shadow_entry() clear shadow entries in `struct folio_batch`
> so that it can reduce contention on i_lock and i_pages locks, e.g.,
> 
>   watchdog: BUG: soft lockup - CPU#29 stuck for 11s! [fio:2701649]
>     clear_shadow_entry+0x3d/0x100
>     mapping_try_invalidate+0x117/0x1d0
>     invalidate_mapping_pages+0x10/0x20
>     invalidate_bdev+0x3c/0x50
>     blkdev_common_ioctl+0x5f7/0xa90
>     blkdev_ioctl+0x109/0x270

This will clearly reduce lock traffic a lot, but does it truly fix the
issue?  Is it the case that sufficiently extreme loads will still run
into problems?

> --- a/mm/truncate.c
> +++ b/mm/truncate.c
> @@ -39,12 +39,24 @@ static inline void __clear_shadow_entry(struct address_space *mapping,
>  	xas_store(&xas, NULL);
>  }
>  
> -static void clear_shadow_entry(struct address_space *mapping, pgoff_t index,
> -			       void *entry)
> +static void clear_shadow_entry(struct address_space *mapping,
> +			       struct folio_batch *fbatch, pgoff_t *indices)
>  {
> +	int i;
> +
> +	if (shmem_mapping(mapping) || dax_mapping(mapping))
> +		return;

We lost the comment which was in invalidate_exceptional_entry() and
elsewhere.  It wasn't a terribly good one but I do think a few words
which explain why we're testing for these things would be helpful.

I expect we should backport this.  But identifying a Fixes: target
looks to be challenging.