From: "Xu Xin (vivo)" <xu.xin@linux.dev>
To: david@kernel.org
Cc: chengming.zhou@linux.dev, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, ljs@kernel.org, xu.xin@linux.dev
Subject: Re: [PATCH 2/2] mm/ksm: add initialization helpers for scan_get_next_rmap_item()
Date: Sat, 14 Nov 2026 22:43:38 +0800 [thread overview]
Message-ID: <20261114144338.644122-1-xu.xin@linux.dev> (raw)
In-Reply-To: <00521fb1-121d-4aef-9278-fb6b36755291@kernel.org>
> > diff --git a/mm/ksm.c b/mm/ksm.c
> > index 49977bcf04f7..e79e64372e49 100644
> > --- a/mm/ksm.c
> > +++ b/mm/ksm.c
> > @@ -2640,6 +2640,49 @@ static void ksm_reset_unstable_trees(void)
> > root_unstable_tree[nid] = RB_ROOT;
> > }
> >
> > +static bool scan_begin_new_cycle(void)
> > +{
> > + /* Check if the cursor points to the head. */
> > + if (ksm_scan.mm_slot != &ksm_mm_head)
> > + return false;
> > +
> > + /*
> > + * A number of pages can hang around indefinitely in per-cpu
> > + * LRU cache, raised page count preventing write_protect_page
> > + * from merging them. Though it doesn't really matter much,
> > + * it is puzzling to see some stuck in pages_volatile until
> > + * other activity jostles them out, and they also prevented
> > + * LTP's KSM test from succeeding deterministically; so drain
> > + * them here (here rather than on entry to ksm_do_scan(),
> > + * so we don't IPI too often when pages_to_scan is set low).
> > + */
> > + lru_add_drain_all();
> > + return true;
> > +}
> > +
>
> Can we just leave the lru_add_drain_all() where it is, or what's the reason for
> that change?
Sure, There was no special reason for moving lru_add_drain_all()—I just wanted to
keep low-level details out of the main scan function to make it look cleaner.
Since it is going to be removed soon anyway, leaving it in place makes total
sense.
>
> Note that that might soon get removed either way, so I wouldn't worry about it.
>
> Then, I would rename the function into something like
>
> "scan_should_start_new_cycle"
>
> And keep it simple.
I will rename the helper to scan_should_start_new_cycle(), keep it simple,
and send out v2 shortly.
prev parent reply other threads:[~2026-11-14 14:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 12:57 [PATCH 0/2] mm/ksm: clean up scan_get_next_rmap_item() initialization Xu Xin (vivo)
2026-11-12 12:59 ` [PATCH 1/2] mm/ksm: extract helper functions for scan cycle cleanup Xu Xin (vivo)
2026-11-13 14:03 ` Lorenzo Stoakes (ARM)
2026-11-13 19:07 ` David Hildenbrand (Arm)
2026-11-12 12:59 ` [PATCH 2/2] mm/ksm: add initialization helpers for scan_get_next_rmap_item() Xu Xin (vivo)
2026-11-13 13:00 ` sashiko-bot
2026-11-13 14:09 ` Lorenzo Stoakes (ARM)
2026-11-14 14:56 ` Xu Xin (vivo)
2026-11-13 19:10 ` David Hildenbrand (Arm)
2026-11-14 14:43 ` Xu Xin (vivo) [this message]
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=20261114144338.644122-1-xu.xin@linux.dev \
--to=xu.xin@linux.dev \
--cc=chengming.zhou@linux.dev \
--cc=david@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
/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.