From: "Jose A. Perez de Azpillaga" <azpijr@gmail.com>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Cc: David Hildenbrand <david@kernel.org>, Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
"Liam R. Howlett" <liam@infradead.org>,
Nico Pache <nico.pache@linux.dev>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Lance Yang <lance.yang@linux.dev>,
Usama Arif <usama.arif@linux.dev>,
Kiryl Shutsemau <kas@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] mm/khugepaged: release contended mmap read lock after scanning enough VMAs
Date: Fri, 6 Nov 2026 11:49:20 +0100 [thread overview]
Message-ID: <1188802c-3661-441d-85a7-3ac68042e022@gmail.com> (raw)
In-Reply-To: <au2sZrlidH_f39kL@gremlin>
On 11/6/26 11:33 AM, Lorenzo Stoakes (ARM) wrote:
> On Fri, Nov 06, 2026 at 11:29:00AM +0100, Jose A. Perez de Azpillaga wrote:
>>>> with pages_to_scan below 4 the batch is 0, so under constant contention
>>>> we keep dropping the lock at the cursor and never scan anything, don't we?
>>>
>>> This feels like repackaged AI review...
>>>
>>> The mmap lock won't be eternally contended and if it is, with pages_to_scan
>>> under 4, I think that's fine.
>>>
>>> Alternatively could make that >= an == and the post-++ a pre-++ and the 0 will
>>> never be hit in this case.
>>>
>>> Or could have a minimum cap.
>>
>> with >= a minimum cap needs to be 2, since the cursor can stop at hend
>> inside the VMA we just scanned and the walk lands on it again after the
>> drop. with == only batch - 1 VMAs get scanned per cycle, so a batch of 1
>> scans nothing, today's batch-0 loop at pages_to_scan 4..7, and a batch
>> of 2 hits the hend case. it's safe from 3 up.
>
> Please don't copy/paste LLM responses. I'm sure it's in good faith, but it's not
> helpful. I will run any changes through AI myself.
it wasn't my intention. I am bad at writing reviews, so AI assists me to
reword it, so it's polished, and I still check all the output. now
onward, maybe my reviews get a bit clumsy, and not polished. I will stop
rewording them.
--
cheers,
jose a. p-a
next prev parent reply other threads:[~2026-11-06 10:49 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 20:57 [PATCH v2 0/3] mm/khugepaged: bound mmap_lock hold time when walking an mm's VMAs Lorenzo Stoakes (ARM)
2026-11-05 20:57 ` [PATCH v2 1/3] Revert "mm/khugepaged: remove definition of struct khugepaged_mm_slot" Lorenzo Stoakes (ARM)
2026-11-05 21:47 ` Jose A. Perez de Azpillaga
2026-11-06 9:41 ` Baolin Wang
2026-11-05 20:57 ` [PATCH v2 2/3] mm/khugepaged: scan mm's more efficiently under mmap_lock contention Lorenzo Stoakes (ARM)
2026-11-05 21:48 ` Jose A. Perez de Azpillaga
2026-11-06 9:31 ` Baolin Wang
2026-11-05 20:57 ` [PATCH v2 3/3] mm/khugepaged: release contended mmap read lock after scanning enough VMAs Lorenzo Stoakes (ARM)
2026-11-05 21:53 ` Jose A. Perez de Azpillaga
2026-11-06 10:03 ` Lorenzo Stoakes (ARM)
2026-11-06 10:29 ` Jose A. Perez de Azpillaga
2026-11-06 10:33 ` Lorenzo Stoakes (ARM)
2026-11-06 10:49 ` Jose A. Perez de Azpillaga [this message]
2026-11-06 2:12 ` Vernon Yang
2026-11-06 9:29 ` Vernon Yang
2026-11-06 10:49 ` Lorenzo Stoakes (ARM)
2026-11-06 9:38 ` Baolin Wang
2026-11-06 10:52 ` Lorenzo Stoakes (ARM)
2026-11-06 12:07 ` Lorenzo Stoakes (ARM)
2026-11-06 12:23 ` Lorenzo Stoakes (ARM)
2026-11-06 13:26 ` Vernon Yang
2026-11-06 15:24 ` Lorenzo Stoakes (ARM)
2026-11-06 15:39 ` Lorenzo Stoakes (ARM)
2026-11-09 14:01 ` David Hildenbrand (Arm)
2026-11-09 14:12 ` Lorenzo Stoakes (ARM)
2026-11-09 15:00 ` David Hildenbrand (Arm)
2026-11-06 20:58 ` sashiko-bot
2026-11-10 17:05 ` Lorenzo Stoakes (ARM)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1188802c-3661-441d-85a7-3ac68042e022@gmail.com \
--to=azpijr@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=kas@kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=nico.pache@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=usama.arif@linux.dev \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.