From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF500C36000 for ; Fri, 21 Mar 2025 17:29:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 52D8D280004; Fri, 21 Mar 2025 13:29:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4DC4C280001; Fri, 21 Mar 2025 13:29:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 37C8B280004; Fri, 21 Mar 2025 13:29:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1A73C280001 for ; Fri, 21 Mar 2025 13:29:49 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 5013F160423 for ; Fri, 21 Mar 2025 17:29:49 +0000 (UTC) X-FDA: 83246245698.30.113633C Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf07.hostedemail.com (Postfix) with ESMTP id 3F0C840006 for ; Fri, 21 Mar 2025 17:29:47 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742578187; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AE/JAsHN6FVj2O3CZ90rWLeXebeRbEGxcpTjJYniFpg=; b=jbJj3SAxV5J9b261f5H2DDEnBWo0z33HykdBl7+np02UjJY+w1qofrO6UlD56RK0FDqQom Fml4BI+E7CL1JC1C6Y6Uitb/3K8T9tPdAEsH3g6pnV/CBTIGOI7/RiVogxKt3caHkLb2hv gf2uKojp0uh0YsVfYuWcbpmI6p30MOU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742578187; a=rsa-sha256; cv=none; b=aP+DEkzWHC3OF08AE/uemxDf7d+He9cdjzxGc9+iVpoiLIJNWQkV1Lgs65kncS1sjQcr9y 0rTMVsXhpTHSekVXDb18sOv7BiJVa6s5USA4sitmGDDcjiZi4aPmU9doyeLONDPZgsMd60 e1dOvRoNWuKd6l3pzWyremMQgjc1aeE= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4ZK8WQ3MCsz6K9BM; Sat, 22 Mar 2025 01:26:42 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id BD980140142; Sat, 22 Mar 2025 01:29:43 +0800 (CST) Received: from localhost (10.203.177.66) by frapeml500008.china.huawei.com (7.182.85.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Fri, 21 Mar 2025 18:29:42 +0100 Date: Fri, 21 Mar 2025 17:29:40 +0000 From: Jonathan Cameron To: Raghavendra K T CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [RFC PATCH V1 04/13] mm: Create a separate kernel thread for migration Message-ID: <20250321172940.00007646@huawei.com> In-Reply-To: <20250319193028.29514-5-raghavendra.kt@amd.com> References: <20250319193028.29514-1-raghavendra.kt@amd.com> <20250319193028.29514-5-raghavendra.kt@amd.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.203.177.66] X-ClientProxiedBy: lhrpeml100010.china.huawei.com (7.191.174.197) To frapeml500008.china.huawei.com (7.182.85.71) X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 3F0C840006 X-Stat-Signature: gx5mzcy53zyyfxbp3uqrmpbazq8k1nrb X-HE-Tag: 1742578187-185500 X-HE-Meta: U2FsdGVkX1+t26fhqkoDjggUYjx1/L/V5FMKttAEuGzt2rU3HmSrB19j5KdctHgtAXI//FAzYXLq/v/l1u80mA1IGJqQAmWg7qzwFYiiUnVyb7DvG+V9Myq6XYVouuN1XLnwKF4qh1WT0Ig2ZtDgA+PijuT3KS/HldWpeTPpcjXjHssMmZMaWVlWhnb30icDOxdVMEeOCqSsG9qdRgiGppPZ6HanG6+8UUYrXaF7HlmE+V8sqoqutLHvgIAD+R0BBNVb0/HLz1U9atEs32ZVA62dR8JlCc6bgzNL+7knCZTxviZlv7f2bVVAnnl7z1ImmDKuilV3MbmK+mZB3TCjFzsakCN/Fvcihh+SEgqhijpycCxs4iwCOOFm+wFpCavV8S1E9P2Wea3rTNerqz0Yc0A0ZMv7WHRwV8p6cOuRogoj6f+ShU9fSV80+w1r1rlcWQsKFIA2ru1rrqwVIZdkRqm47/T6BWYx2Bu60ux6vh/wH8ndTjofWMV1q3rQYPxeONKvlQKGJ79rwjU+LvFvzskuSKNhxKcN+N13WxsIOMmn8clEi1C6iINu5FcoV3DN1D89IjFI1FLCwZiGeynkqLzT9sbjyNGxIaSZbli0FGO2LuWkDmOYlLZDD7O5N/HuFsItzLnlftesA9n+mI9+BseTBuUxLUqhreDMj8vlrdUedTtcHgUWG9vZ6EZoANNF9e7ohqNnBwqx+PnMdSs7OiizzzUEnL63/flGqE3W9q3S6CwiFOz3dur+EKkAxtV+U+yk3RCwuNv80smW2DiHOulHLyj4vJFAXEoDRoDJDDpMSco3qlfzMEhtitNk3zyNaa2O44ubVkxfOLwTGt8jPOAK+PZT21b1hZPhA59RLEnmXGteTKxDziTjlLcrCcLH/cpapOOcIiIS+zdJ5nPM/uYFmXTF6HaQ5pqVXpNrQCfVVUIJ7q/MTHzCXyTeMMrLinXjf0CcEiETA+nCBix UWKm0etp uOnBaF0CZaik7nNJ8ZRMmKahWv3fgYSIt1sTTAdUcWiwcPA3OvEvJIdJzg1J/nLcfjLB4qTJ/ZYv0LeDneKYRkyVLN/wKsVERrBOPkOoGeJB08K03/rpxCFjTXYWyoj9xh2/Y+bf4YaTkC7Wek54eJ8Htm7gjSwJf01vqoZ1nh1k5ONssvCjQlhk3EVZGkZ5tnVZQixNhxeUGC3M59HIeT1hH62NOuW/8wl1Sn86UzwonCliBA8NpgYn30RXCLYMYyFC+9Cw/LW6q854= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, 19 Mar 2025 19:30:19 +0000 Raghavendra K T wrote: > Having independent thread helps in: > - Alleviating the need for multiple scanning threads > - Aids to control batch migration (TBD) > - Migration throttling (TBD) > A few comments on things noticed whilst reading through. Jonathan > Signed-off-by: Raghavendra K T > --- > mm/kmmscand.c | 157 +++++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 154 insertions(+), 3 deletions(-) > > diff --git a/mm/kmmscand.c b/mm/kmmscand.c > index a76a58bf37b2..6e96cfab5b85 100644 > --- a/mm/kmmscand.c > +++ b/mm/kmmscand.c > /* Per folio information used for migration */ > struct kmmscand_migrate_info { > struct list_head migrate_node; > @@ -101,6 +126,13 @@ static int kmmscand_has_work(void) > return !list_empty(&kmmscand_scan.mm_head); > } > > +static int kmmmigrated_has_work(void) > +{ > + if (!list_empty(&kmmscand_migrate_list.migrate_head)) > + return true; > + return false; If it isn't getting more complex later, can just return !list_empty(). or indeed, just put that condition directly at caller. > +} > static inline bool is_valid_folio(struct folio *folio) > { > @@ -238,7 +293,6 @@ static int hot_vma_idle_pte_entry(pte_t *pte, > folio_put(folio); > return 0; > } > - /* XXX: Leaking memory. TBD: consume info */ > info = kzalloc(sizeof(struct kmmscand_migrate_info), GFP_NOWAIT); > if (info && scanctrl) { > > @@ -282,6 +336,28 @@ static inline int kmmscand_test_exit(struct mm_struct *mm) > return atomic_read(&mm->mm_users) == 0; > } > > +static void kmmscand_cleanup_migration_list(struct mm_struct *mm) > +{ > + struct kmmscand_migrate_info *info, *tmp; > + > + spin_lock(&kmmscand_migrate_lock); Could scatter some guard() magic in here. > + if (!list_empty(&kmmscand_migrate_list.migrate_head)) { Maybe flip logic of this unless it is going to get more complex in future patches. That way, with guard() handling the spin lock, you can just return when nothing to do. > + if (mm == READ_ONCE(kmmscand_cur_migrate_mm)) { > + /* A folio in this mm is being migrated. wait */ > + WRITE_ONCE(kmmscand_migration_list_dirty, true); > + } > + > + list_for_each_entry_safe(info, tmp, &kmmscand_migrate_list.migrate_head, > + migrate_node) { > + if (info && (info->mm == mm)) { > + info->mm = NULL; > + WRITE_ONCE(kmmscand_migration_list_dirty, true); > + } > + } > + } > + spin_unlock(&kmmscand_migrate_lock); > +} > static unsigned long kmmscand_scan_mm_slot(void) > { > bool next_mm = false; > @@ -347,9 +429,17 @@ static unsigned long kmmscand_scan_mm_slot(void) > > if (vma_scanned_size >= kmmscand_scan_size) { > next_mm = true; > - /* TBD: Add scanned folios to migration list */ > + /* Add scanned folios to migration list */ > + spin_lock(&kmmscand_migrate_lock); > + list_splice_tail_init(&kmmscand_scanctrl.scan_list, > + &kmmscand_migrate_list.migrate_head); > + spin_unlock(&kmmscand_migrate_lock); > break; > } > + spin_lock(&kmmscand_migrate_lock); > + list_splice_tail_init(&kmmscand_scanctrl.scan_list, > + &kmmscand_migrate_list.migrate_head); > + spin_unlock(&kmmscand_migrate_lock); I've stared at this a while, but if we have entered the conditional block above, do we splice the now empty list? > } > > if (!vma)