From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f45.google.com (mail-oo1-f45.google.com [209.85.161.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EB011366054 for ; Tue, 21 Apr 2026 16:05:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776787510; cv=none; b=WGUluZIfRK8K8BTAd6uiRTD//4cWWN5LjHD/zZAZ0Cfykjkq5vY7XszTUClaj0QVrI/+mtKBYFQNzYgU27IXMS9J7ET2Fe7e7NCfb9vSB1wiknZ5UvuuGyJ+oIqX5AvCpaq//6zqkkN6sxg3a1VnONUZlESpwVsNrwaOHmNIiw8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776787510; c=relaxed/simple; bh=eRPUMZUfhUIYHdNFhl0WcoLRryLgcyQ9dKQIeiDHe3Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=m+ZXibpDeEv2yBAb1eEPmux3vm4EfBK76C/cjzB5HPUXXPYdOx5x5zmZ+lwqF+GkoGgvJr9Q9XkHBbmmLWG9wkaYt6Y64a0aOY7GmJ0YgpQphoQt60ihP2tsCpGUygyEERDAyn+iiV0jpzKzzJDFQ9RrY027nr0yQvqP0adSzEY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=H4UCgX5j; arc=none smtp.client-ip=209.85.161.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="H4UCgX5j" Received: by mail-oo1-f45.google.com with SMTP id 006d021491bc7-68244d317e5so2693574eaf.0 for ; Tue, 21 Apr 2026 09:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1776787508; x=1777392308; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=DfR8fZwCFFz0FeFXDfTRURMvD1IDFp6drnOSFVLy1EU=; b=H4UCgX5jyerUSMj3ECelP11pHtZ08S0GSQ7NHNyrEH7ltn9gE3BcN+q//gmGUZNU96 90vU0c44ed5/QzfoS7Ea3ueZWzgF3cDbTjLIGMul2/v28mi4ZE13y/je4Zus8pJtPOXv TXcvjv1FtdF95A338CvkbTijV1KVlI8vJHezJLbe9hKIokOhTBDGAJcA7A4NrQlFuFVW gOR9mcGPEE5/4j7K4D6YJ9zgrtJiecLaVgcXw79XXFb/MmAz6RCrFq1ZAdO/rIei6Kf4 T56rYPqhqf7ii9ow2GwPcGQl56oafiG2aWW507AKJAwbjJZfCLzXLStshrYDV4TbnA23 jElA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776787508; x=1777392308; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DfR8fZwCFFz0FeFXDfTRURMvD1IDFp6drnOSFVLy1EU=; b=imz6uqRVd6a/bqEBVpBwzQ7KVLTf4a5tgdwbbtWM1Mqt7OmyV3uE9/uwlP6AEbGGy9 bVmIjCzDhQnGlDyEu/IQZ/6A1nxWSUKL8HOAa+ExPIz0DAO39y/San20Ds3ARTLhSKSK 610NWj8etWwHPP0cHSlXYen94C4XaSHSWGEgHbPwWF8e/uWpzAKih+SJ1O01bpU0VUFm gAV+d04Cs/sHfKmANzNdTO3++Imd72UD2c9NBNa2cwuUa0WtQZ278dHy0J7zjBHunIeH FvnEIZeY1ZH8/BVG4Jn0Dv8z6xjB232F9BK8v4RNz66UsK7sbx8sTl4hknRYx12rOXXf 4FcA== X-Forwarded-Encrypted: i=1; AFNElJ+KE2YhuLbYL1qQjci2049LJJUao2fGOeFiA0INQ+1YB+a+sVS+mfITe0MdQSiBwuV/Hd44u36iFEUfKDM=@vger.kernel.org X-Gm-Message-State: AOJu0YyygAyw3SsAlkd1MQm6GPtnex0yML0InYl194UZkcG0Q4IZ/uSk cAX1M8+odktl5SD7+TnGK0ueOBXwbO5KdVTICk+Epgc7qhn3gppt3MTFlxRMKdNmwCg= X-Gm-Gg: AeBDiet7jnKXORBYGq3lEWma3Jmn5me/tkpZL6pBsib+u8db1O2td+QxpkKN4z+91hR r0lUjCpt9psRxEN7LF/zlX6OFqtn0cqfqFocBru+hcOT8sW5nmEAJZ3c8LreN7SXLC0ug3kR9VB nW8KOXls4rScUSKdamDAcJYifLYc7NAwySo0rU6ksJatAPPDItQVRS+crJSW1aQEs5SF6pcmJUb hySFEKmam64+9EPYhSdFEleeM+/UBY8NPKBlCYf+TQfRUS9oyh7wdKVtPCbZw26j6AAnLPTW2Py N/GZAK/RKTU4TTOZJZEsVZqgYjjwWff4QMKzdq4PJl6Fi8KThLIue2ZAstd8mRBKvP9ITfYyLqd ZiXoGi4T+YU9WymJSjRRlmROvwH2gr0Uc/IVSApKK56OiN6C+jLRVjggCxRet6az0gQ6U0ZhO9w lJRO9BDMn2iHxVUSdsXVH1lbLNyO3SOpjqgkzkh514p+BsAEuQPNo8eaMh4Gsn5lPEFOzANqH3m gX4bTmHnpt9qcYSCE2i X-Received: by 2002:a05:6820:1796:b0:68c:6e:89d1 with SMTP id 006d021491bc7-69462f31c5dmr11175838eaf.41.1776787507683; Tue, 21 Apr 2026 09:05:07 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-71-246-228-50.washdc.fios.verizon.net. [71.246.228.50]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8e7d69ad48asm1059065885a.19.2026.04.21.09.05.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Apr 2026 09:05:06 -0700 (PDT) Date: Tue, 21 Apr 2026 12:05:03 -0400 From: Gregory Price To: Donet Tom Cc: Bharata B Rao , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Jonathan.Cameron@huawei.com, dave.hansen@intel.com, mgorman@techsingularity.net, mingo@redhat.com, peterz@infradead.org, raghavendra.kt@amd.com, riel@surriel.com, rientjes@google.com, sj@kernel.org, weixugc@google.com, willy@infradead.org, ying.huang@linux.alibaba.com, ziy@nvidia.com, dave@stgolabs.net, nifan.cxl@gmail.com, xuezhengchu@huawei.com, yiannis@zptcorp.com, akpm@linux-foundation.org, david@redhat.com, byungchul@sk.com, kinseyho@google.com, joshua.hahnjy@gmail.com, yuanchu@google.com, balbirs@nvidia.com, alok.rathore@samsung.com, shivankg@amd.com Subject: Re: [RFC PATCH v6 2/5] mm: migrate: Add migrate_misplaced_folios_batch() Message-ID: References: <20260323095104.238982-1-bharata@amd.com> <20260323095104.238982-3-bharata@amd.com> <24cd6a95-1304-4732-9273-43c73ea858b2@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <24cd6a95-1304-4732-9273-43c73ea858b2@linux.ibm.com> On Tue, Apr 21, 2026 at 08:55:02PM +0530, Donet Tom wrote: > > Hi Bharata > > On 3/23/26 3:21 PM, Bharata B Rao wrote: > > From: Gregory Price > > > > Tiered memory systems often require migrating multiple folios at once. > > Currently, migrate_misplaced_folio() handles only one folio per call, > > which is inefficient for batch operations. This patch introduces > > migrate_misplaced_folios_batch(), a batch variant that leverages > > migrate_pages() internally for improved performance. > > > > The caller must isolate folios beforehand using > > migrate_misplaced_folio_prepare(). On return, the folio list will be > > empty regardless of success or failure. > > > > This function will be used by pghot kmigrated thread. > > > > Signed-off-by: Gregory Price > > [Rewrote commit description] > > Signed-off-by: Bharata B Rao > > --- > > include/linux/migrate.h | 6 ++++++ > > mm/migrate.c | 48 +++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 54 insertions(+) > > > > diff --git a/include/linux/migrate.h b/include/linux/migrate.h > > index d5af2b7f577b..5c1e2691cec2 100644 > > --- a/include/linux/migrate.h > > +++ b/include/linux/migrate.h > > @@ -111,6 +111,7 @@ static inline void softleaf_entry_wait_on_locked(softleaf_t entry, spinlock_t *p > > int migrate_misplaced_folio_prepare(struct folio *folio, > > struct vm_area_struct *vma, int node); > > int migrate_misplaced_folio(struct folio *folio, int node); > > +int migrate_misplaced_folios_batch(struct list_head *folio_list, int node); > > #else > > static inline int migrate_misplaced_folio_prepare(struct folio *folio, > > struct vm_area_struct *vma, int node) > > @@ -121,6 +122,11 @@ static inline int migrate_misplaced_folio(struct folio *folio, int node) > > { > > return -EAGAIN; /* can't migrate now */ > > } > > +static inline int migrate_misplaced_folios_batch(struct list_head *folio_list, > > + int node) > > +{ > > + return -EAGAIN; /* can't migrate now */ > > +} > > #endif /* CONFIG_NUMA_BALANCING */ > > #ifdef CONFIG_MIGRATION > > diff --git a/mm/migrate.c b/mm/migrate.c > > index a15184950e65..94daec0f49ef 100644 > > --- a/mm/migrate.c > > +++ b/mm/migrate.c > > @@ -2751,5 +2751,53 @@ int migrate_misplaced_folio(struct folio *folio, int node) > > BUG_ON(!list_empty(&migratepages)); > > return nr_remaining ? -EAGAIN : 0; > > } > > + > > +/** > > + * migrate_misplaced_folios_batch() - Batch variant of migrate_misplaced_folio > > + * Attempts to migrate a folio list to the specified destination. > > + * @folio_list: Isolated list of folios to be batch-migrated. > > + * @node: The NUMA node ID to where the folios should be migrated. > > + * > > + * Caller is expected to have isolated the folios by calling > > + * migrate_misplaced_folio_prepare(), which will result in an > > + * elevated reference count on the folio. All the isolated folios > > + * in the list must belong to the same memcg so that NUMA_PAGE_MIGRATE > > + * stat can be attributed correctly to the memcg. > > + * > > + * This function will un-isolate the folios, drop the elevated reference > > + * and remove them from the list before returning. This is called > > + * only for batched promotion of hot pages from lower tier nodes. > > + * > > + * Return: 0 on success and -EAGAIN on failure or partial migration. > > + * On return, @folio_list will be empty regardless of success/failure. > > + */ > > +int migrate_misplaced_folios_batch(struct list_head *folio_list, int node) > > +{ > > + pg_data_t *pgdat = NODE_DATA(node); > > + struct mem_cgroup *memcg = NULL; > > + unsigned int nr_succeeded = 0; > > + int nr_remaining; > > + > > + if (!list_empty(folio_list)) { > > > We seem to proceed even when the list is empty. Should we instead return > early in that case? > Well that seems utterly reasonable, yes you are right. > > + struct folio *first = list_first_entry(folio_list, struct folio, lru); > > + memcg = get_mem_cgroup_from_folio(first); > > > I had a small question—are we ensuring that a single list contains folios > from the same memcg? > It has been a long while since i originally wrote this commit. I believe I originally wrote this I used it in the context of folio_mark_accessed() driven promotions - trying to get some semblance of NUMA balancing for unmapped page cache pages. These folios got put into a task workqueue that then got processed on the way out of the kernel. I think I made the assumption at the time that the folios would all belong to the same memcg - I have since learned that this almost certainly is not the case. That means a bulk migration may have to first process the folios into lists by memcg before migrating them. So this commit likely needs to be redone. ~Gregory