On Mon, 8 Jul 2024 15:27:53 -0600 Yu Zhao <yuzhao@xxxxxxxxxx> 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.
