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 F1E9CC7115B for ; Fri, 20 Jun 2025 06:40:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 775326B007B; Fri, 20 Jun 2025 02:40:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74C736B0089; Fri, 20 Jun 2025 02:40:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 662896B008A; Fri, 20 Jun 2025 02:40:05 -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 55BD16B007B for ; Fri, 20 Jun 2025 02:40:05 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id EDC92818D5 for ; Fri, 20 Jun 2025 06:40:04 +0000 (UTC) X-FDA: 83574829128.29.C95B197 Received: from out30-97.freemail.mail.aliyun.com (out30-97.freemail.mail.aliyun.com [115.124.30.97]) by imf06.hostedemail.com (Postfix) with ESMTP id 86845180002 for ; Fri, 20 Jun 2025 06:40:01 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=IGhrS2V4; spf=pass (imf06.hostedemail.com: domain of ying.huang@linux.alibaba.com designates 115.124.30.97 as permitted sender) smtp.mailfrom=ying.huang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750401603; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=gTbWGErp3uEQSrgLXr90+6lbvGnyC2JPi/dFkNyH/eM=; b=5Q9iFQejDzSc8HovqzJtB2cl2auyUlkQFo4j9CpRvezrKXJIa6mIKjIeE9ZsHwzaquORwZ Mvq7lmnOamgb7MIwfWj2XVSmgSaqzNEfKK8pG8JjQhgTeLC0GWu9qoQNSl1cib7nDyDJfo HGZPneyT7t83JuRmvfUp3L4hLZp94d4= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=IGhrS2V4; spf=pass (imf06.hostedemail.com: domain of ying.huang@linux.alibaba.com designates 115.124.30.97 as permitted sender) smtp.mailfrom=ying.huang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750401603; a=rsa-sha256; cv=none; b=ycYNj5ypZhfQzbWA0xF/0mMK1m2S7d85U2AY1jcXQ6UcGfwFOhrrpGwLdPMw0ARdCxnQ5y RRpliSidf3t+o4dBJQXkmF9jnqSkCVNfFILkM/axY4DXbW2EuUBcUURcI+HnF0fSxha1uq 9WYteVBtmkpNb7ZmemYRMuDGpXw5/4o= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1750401598; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=gTbWGErp3uEQSrgLXr90+6lbvGnyC2JPi/dFkNyH/eM=; b=IGhrS2V4c6XcQOv8ddCPbOEgx+++wt9JEvWDT/qfYqXhCwLGrIGE50JosVR+4SVTCL8XAlUaOYOtjwD7tqc1ldqJ9dWKO1XvFaXIk6KQm98aHAcz+t+7g6znSBnBchfIZyfE1v698z9wP7du+wrk9AFeHr+BzDhO2f8d+RzgZ0E= Received: from DESKTOP-5N7EMDA(mailfrom:ying.huang@linux.alibaba.com fp:SMTPD_---0WeJuhrl_1750401595 cluster:ay36) by smtp.aliyun-inc.com; Fri, 20 Jun 2025 14:39:56 +0800 From: "Huang, Ying" To: Bharata B Rao Cc: , , , , , , , , , , , , , , , , , , , , , Subject: Re: [RFC PATCH v1 0/4] Kernel thread based async batch migration In-Reply-To: <20250616133931.206626-1-bharata@amd.com> (Bharata B. Rao's message of "Mon, 16 Jun 2025 19:09:27 +0530") References: <20250616133931.206626-1-bharata@amd.com> Date: Fri, 20 Jun 2025 14:39:54 +0800 Message-ID: <87bjqi3ohx.fsf@DESKTOP-5N7EMDA> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: 86845180002 X-Stat-Signature: w5sq7mbcdc5si8t8r1b84zwyn7k3c6ya X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1750401601-454932 X-HE-Meta: U2FsdGVkX18sE6PNCjVTOwt8EycCj3hBhJIMJAFRJgv7r+h+ZeYo5vcAT4u+w2EqBua47vQ2Yk6vt8sOc64YNzzKKv0OTvkVv8/v9hIqtvUb1bRpAst94zaBhxVCvJcjKIlyi1wRDpEYH4LBCBkQwGaSYWl3IdyvgjF+2uiYOTfSTjclDmPs6eMVvZd+MY0InGngKptqpMDBqqRWdVY7kQ499eA0pDkrQK9AvZEzGecMhAfWIKgVo7ISSruDYR2N1pKUdxTZ61/+YmEoquZmkkQvJz/fHMn5d40SLGl+hPgleCrhU8pKw0A78A95vUiVrzmWgmArFDuSx7djOz+KoCOiuco030RhFi9ovbd9uYWfQ07JVVbj9sikLvKTqn+bpDAyN7n0SJXXxtbFwZ8dQNFBRQ6zwnsonZmKTjdKEUJER+u6SXAiamRkcmMDgGZHgP++WEBPpTM8Ak11NSnCr7JYPcXXmNIACFGPGIy/q02US3dkn+B0DJ2L2gy9cAG1SG1LcHYCJzvi5sLk8CF/mFkNtyL3y99A3UzcEHoojToCEQ3Px5dUfHCGnYqcGsOL+4KSNTb4OC2gRAxv/Q59cmpiN6FqNwp3HkZh4/ih9GAWDwVmYDExGn/6GJTzmj2kWCBuxLjPp5F7tORqu9Jeaf1Dra73Hp/XSl94sEAPgm05S1UjYW6xe7VMpfZENFVK5kpdB08nNaTYrWgbc56mRal//XWtGOSkEjlHUTEns0JU1P1cw4SHi7F9rzEyzoggy5XARTWJeS23l2JNs0ryWl6v5Z58cHP8KV3hm5NHFnxR3pE0qg/sfpC27zyPrVoSvdvMtwyBw6S0i+AinPtrR3tzDYSLcJzieMw2KO+xCN1E3+GgOLv0H0KxM2rCIKEggZZFXgktfuBMFfk39y5NfP1jxrhTO0xvgJ7WcQzvEdqHs9Ync0nTxGXSo1+WACum 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: Bharata B Rao writes: > Hi, > > This is a continuation of the earlier post[1] that attempted to > convert migrations from NUMA Balancing to be async and batched. > In this version, per-node kernel threads are created to handle > migrations in an async manner. > > This adds a few fields to the extended page flags that can be > used both by the sub-systems that request migrations and kmigrated > which migrates the pages. Some of the fields are potentially defined > to be used by kpromoted-like subsystem to manage hot page metrics, > but are unused right now. > > Currently only NUMA Balancing is changed to make use of the async > batched migration. It does so by recording the target NID and the > readiness of the page to be migrated in the extended page flags > fields. > > Each kmigrated routinely scans its PFNs, identifies the pages > marked for migration and batch-migrates them. Unlike the previous > approach, the responsibility of isolating the pages is now with > kmigrated. > > The major difference between this approach and the way kpromoted[2] > tracked hot pages is the elimination of heavy synchronization points > between producers(sub-systems that request migrations or report > a hot page) and the consumer (kmigrated or kpromoted). > Instead of tracking only the list of hot pages in an orthogonal > manner, this approach ties the hot page or migration infomation > to the struct page. I don't think page flag + scanning is a good idea. If the synchronization is really a problem for you (based on test results), some per-CPU data structure can be used to record candidate pages. [snip] --- Best Regards, Huang, Ying