Re: [PATCH v3 3/3] mm/khugepaged: release contended mmap read lock after scanning enough VMAs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] mm/khugepaged: stale jiffies-based check description in commit
  message
--

commit bce7aeac77f8f4e7344a0f568e13d01a781dac5f
Author: Lorenzo Stoakes (ARM) <ljs@kernel.org>

mm/khugepaged: release contended mmap read lock after scanning enough VMAs

This commit drops and reacquires the mmap read lock in
collapse_scan_mm_slot() if the lock is contended after walking a batch of
1024 VMAs.

Link: https://lore.kernel.org/all/20261105-rwsem-dont-steal-from-queued-writer-v1-1-275e070f426f@kernel.org/

> Address this by checking whether the mmap lock is contended after 1-10
> ms (depending on CONFIG_HZ), i.e. the granularity of jiffies. This is a
> long time for a lock to be held, so is a reasonable compromise for
> determining when best to do this.

[Severity: Low]
Is this paragraph left over from an earlier jiffies-based version of the
patch?  The code checks mmap_lock_is_contended() every
KHUGEPAGED_MAX_VMA_SCAN_BATCH (1024) VMAs, as described in the following
paragraph, rather than using jiffies.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110-khugepaged-latency-fix-v3-0-6eea743cf9a3@kernel.org?part=3