From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Raghavendra K T <raghavendra.kt@amd.com>
Cc: <AneeshKumar.KizhakeVeetil@arm.com>, <Michael.Day@amd.com>,
<akpm@linux-foundation.org>, <bharata@amd.com>,
<dave.hansen@intel.com>, <david@redhat.com>,
<dongjoo.linux.dev@gmail.com>, <feng.tang@intel.com>,
<gourry@gourry.net>, <hannes@cmpxchg.org>, <honggyu.kim@sk.com>,
<hughd@google.com>, <jhubbard@nvidia.com>, <jon.grimm@amd.com>,
<k.shutemov@gmail.com>, <kbusch@meta.com>,
<kmanaouil.dev@gmail.com>, <leesuyeon0506@gmail.com>,
<leillc@google.com>, <liam.howlett@oracle.com>,
<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
<mgorman@techsingularity.net>, <mingo@redhat.com>,
<nadav.amit@gmail.com>, <nphamcs@gmail.com>,
<peterz@infradead.org>, <riel@surriel.com>, <rientjes@google.com>,
<rppt@kernel.org>, <santosh.shukla@amd.com>, <shivankg@amd.com>,
<shy828301@gmail.com>, <sj@kernel.org>, <vbabka@suse.cz>,
<weixugc@google.com>, <willy@infradead.org>,
<ying.huang@linux.alibaba.com>, <ziy@nvidia.com>,
<dave@stgolabs.net>, <yuanchu@google.com>, <kinseyho@google.com>,
<hdanton@sina.com>, <harry.yoo@oracle.com>
Subject: Re: [RFC PATCH V3 02/17] mm: Maintain mm_struct list in the system
Date: Thu, 2 Oct 2025 14:23:15 +0100 [thread overview]
Message-ID: <20251002142315.000072f2@huawei.com> (raw)
In-Reply-To: <20250814153307.1553061-3-raghavendra.kt@amd.com>
On Thu, 14 Aug 2025 15:32:52 +0000
Raghavendra K T <raghavendra.kt@amd.com> wrote:
> The list is used to iterate over all the mm and do PTE A bit scanning.
> mm_slot infrastructure is reused to aid insert and lookup of mm_struct.
>
> CC: linux-fsdevel@vger.kernel.org
This is part of the tags block. Some tools moan if you have blank lines
in that. Alternatively push it below the --- and it won't end up in
the git commit but tooling will still add the +CC.
>
> Suggested-by: Bharata B Rao <bharata@amd.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@amd.com>
A few minor comments on formatting.
> diff --git a/mm/kscand.c b/mm/kscand.c
> index f7bbbc70c86a..d5b0d3041b0f 100644
> --- a/mm/kscand.c
> +++ b/mm/kscand.c
> +void __kscand_enter(struct mm_struct *mm)
> +{
> + struct kscand_mm_slot *kscand_slot;
> + struct mm_slot *slot;
> + int wakeup;
> +
> + /* __kscand_exit() must not run from under us */
> + VM_BUG_ON_MM(kscand_test_exit(mm), mm);
> +
> + kscand_slot = mm_slot_alloc(kscand_slot_cache);
> +
Similar to below. I'd keep call and error check more closely coupled
visually by dropping this blank line.
> + if (!kscand_slot)
> + return;
> +
> + slot = &kscand_slot->slot;
> +
> + spin_lock(&kscand_mm_lock);
> + mm_slot_insert(kscand_slots_hash, mm, slot);
> +
> + wakeup = list_empty(&kscand_scan.mm_head);
Looks familiar.
wakeup = kscand_has_work()
Or maybe just get rid of that helper and check it explicitly like this.
> + list_add_tail(&slot->mm_node, &kscand_scan.mm_head);
> + spin_unlock(&kscand_mm_lock);
> +
> + mmgrab(mm);
> + if (wakeup)
> + wake_up_interruptible(&kscand_wait);
> +}
> +
> static int start_kscand(void)
> {
> struct task_struct *kthread;
> @@ -149,6 +228,12 @@ static int __init kscand_init(void)
> {
> int err;
>
> + kscand_slot_cache = KMEM_CACHE(kscand_mm_slot, 0);
> +
I'd drop this blank line. Keep the call and the error check tightly coupled
in one block of code.
> + if (!kscand_slot_cache) {
> + pr_err("kscand: kmem_cache error");
> + return -ENOMEM;
> + }
> err = start_kscand();
> if (err)
> goto err_kscand;
> @@ -157,6 +242,7 @@ static int __init kscand_init(void)
>
> err_kscand:
> stop_kscand();
> + kscand_destroy();
>
> return err;
> }
next prev parent reply other threads:[~2025-10-02 13:23 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-14 15:32 [RFC PATCH V3 00/17] mm: slowtier page promotion based on PTE A bit Raghavendra K T
2025-08-14 15:32 ` [RFC PATCH V3 01/17] mm: Add kscand kthread for PTE A bit scan Raghavendra K T
2025-10-02 13:12 ` Jonathan Cameron
2025-08-14 15:32 ` [RFC PATCH V3 02/17] mm: Maintain mm_struct list in the system Raghavendra K T
2025-10-02 13:23 ` Jonathan Cameron [this message]
2025-08-14 15:32 ` [RFC PATCH V3 03/17] mm: Scan the mm and create a migration list Raghavendra K T
2025-08-15 19:41 ` kernel test robot
2025-08-18 6:30 ` RaghavendraKT
2025-10-02 13:53 ` Jonathan Cameron
2025-08-14 15:32 ` [RFC PATCH V3 04/17] mm/kscand: Add only hot pages to " Raghavendra K T
2025-10-02 16:00 ` Jonathan Cameron
2025-08-14 15:32 ` [RFC PATCH V3 05/17] mm: Create a separate kthread for migration Raghavendra K T
2025-10-02 16:03 ` Jonathan Cameron
2025-08-14 15:32 ` [RFC PATCH V3 06/17] mm/migration: migrate accessed folios to toptier node Raghavendra K T
2025-10-02 16:17 ` Jonathan Cameron
2025-08-14 15:32 ` [RFC PATCH V3 07/17] mm: Add throttling of mm scanning using scan_period Raghavendra K T
2025-10-02 16:24 ` Jonathan Cameron
2025-08-14 15:32 ` [RFC PATCH V3 08/17] mm: Add throttling of mm scanning using scan_size Raghavendra K T
2025-10-03 9:35 ` Jonathan Cameron
2025-08-14 15:32 ` [RFC PATCH V3 09/17] mm: Add initial scan delay Raghavendra K T
2025-10-03 9:41 ` Jonathan Cameron
2025-08-14 15:33 ` [RFC PATCH V3 10/17] mm: Add a heuristic to calculate target node Raghavendra K T
2025-10-03 10:04 ` Jonathan Cameron
2025-08-14 15:33 ` [RFC PATCH V3 11/17] mm/kscand: Implement migration failure feedback Raghavendra K T
2025-10-03 10:10 ` Jonathan Cameron
2025-08-14 15:33 ` [RFC PATCH V3 12/17] sysfs: Add sysfs support to tune scanning Raghavendra K T
2025-10-03 10:25 ` Jonathan Cameron
2025-08-14 15:33 ` [RFC PATCH V3 13/17] mm/vmstat: Add vmstat counters Raghavendra K T
2025-08-14 15:33 ` [RFC PATCH V3 14/17] trace/kscand: Add tracing of scanning and migration Raghavendra K T
2025-10-03 10:28 ` Jonathan Cameron
2025-08-14 15:33 ` [RFC PATCH V3 15/17] prctl: Introduce new prctl to control scanning Raghavendra K T
2025-08-14 15:33 ` [RFC PATCH V3 16/17] prctl: Fine tune scan_period with prctl scale param Raghavendra K T
2025-08-14 15:33 ` [RFC PATCH V3 17/17] mm: Create a list of fallback target nodes Raghavendra K T
2025-08-21 15:24 ` [RFC PATCH V3 00/17] mm: slowtier page promotion based on PTE A bit Raghavendra K T
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=20251002142315.000072f2@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=AneeshKumar.KizhakeVeetil@arm.com \
--cc=Michael.Day@amd.com \
--cc=akpm@linux-foundation.org \
--cc=bharata@amd.com \
--cc=dave.hansen@intel.com \
--cc=dave@stgolabs.net \
--cc=david@redhat.com \
--cc=dongjoo.linux.dev@gmail.com \
--cc=feng.tang@intel.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=harry.yoo@oracle.com \
--cc=hdanton@sina.com \
--cc=honggyu.kim@sk.com \
--cc=hughd@google.com \
--cc=jhubbard@nvidia.com \
--cc=jon.grimm@amd.com \
--cc=k.shutemov@gmail.com \
--cc=kbusch@meta.com \
--cc=kinseyho@google.com \
--cc=kmanaouil.dev@gmail.com \
--cc=leesuyeon0506@gmail.com \
--cc=leillc@google.com \
--cc=liam.howlett@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=nadav.amit@gmail.com \
--cc=nphamcs@gmail.com \
--cc=peterz@infradead.org \
--cc=raghavendra.kt@amd.com \
--cc=riel@surriel.com \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=santosh.shukla@amd.com \
--cc=shivankg@amd.com \
--cc=shy828301@gmail.com \
--cc=sj@kernel.org \
--cc=vbabka@suse.cz \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=ying.huang@linux.alibaba.com \
--cc=yuanchu@google.com \
--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.