include/linux/migrate.h | 6 ++++ include/linux/sched.h | 4 +++ init/init_task.c | 2 ++ kernel/sched/fair.c | 64 +++++++++++++++++++++++++++++++++++++++++ mm/memory.c | 44 ++++++++++++++-------------- mm/migrate.c | 31 ++++++++++++++++++++ 6 files changed, 130 insertions(+), 21 deletions(-)
Hi, This is an attempt to convert the NUMA balancing to do batched migration instead of migrating one folio at a time. The basic idea is to collect (from hint fault handler) the folios to be migrated in a list and batch-migrate them from task_work context. More details about the specifics are present in patch 2/2. During LSFMM[1] and subsequent discussions in MM alignment calls[2], it was suggested that separate migration threads to handle migration or promotion request may be desirable. Existing NUMA balancing, hot page promotion and other future promotion techniques could off-load migration part to these threads. Or if we manage to have a single source of hotness truth like kpromoted[3], then that too can hand over migration requests to the migration threads. I am envisaging that different hotness sources like kmmscand[4], MGLRU[5], IBS[6] and CXL HMU would push hot page info to kpromoted, which would then isolate and push the folios to be promoted to the migrator thread. As a first step, this is an attempt to batch and perform NUMAB migrations in async manner. Separate migration threads aren't yet implemented but I am using Gregory's patch[7] that provides migrate_misplaced_folio_batch() API to do batch migration of misplaced folios. Some points for discussion -------------------------- 1. To isolate the misplaced folios or not? To do batch migration, the misplaced folios need to be stored in some manner. I thought isolating them and using the folio->lru field to link them up would be the most straight-forward way. But then there were concerns expressed about folios remaining isolated for long until they get migrated. Or should we just maintain the PFNs instead of folios and isolate them only just prior to migrating them? 2. Managing target_nid for misplaced pages NUMAB provides the accurate target_nid for each folio that is detected as misplaced. However when we don't migrate the folio right away, but instead want to batch and do asyn migration later, then where do we keep track of target_nid for each folio? In this implementation, I am using last_cpupid field as it appeared that this field could be reused (with some challenges mentioned in 2/2) for isolated folios. This approach may be specific to NUMAB but then each sub-system that hands over pages to the migrator thread should also provide a target_nid and hence each sub-system should be free to maintain and track the target_nid of folios that it has isolated/batched for migration in its own specific manner. 3. How many folios to batch? Currently I have a fixed threshold for number of folios to batch. It could be a sysctl to allow a setting between a min and max. It could also be auto-tuned if required. The state of the patchset ------------------------- * Still raw and very lightly tested * Just posted to serve as base for subsequent discussions here and in MM alignment calls. References ---------- [1] LSFMM LWN summary - https://lwn.net/Articles/1016519/ [2] MM alignment call summary - https://lore.kernel.org/linux-mm/263d7140-c343-e82e-b836-ec85c52b54eb@google.com/ [3] kpromoted patchset - https://lore.kernel.org/linux-mm/20250306054532.221138-1-bharata@amd.com/ [4] Kmmscand: PTE A bit scanning - https://lore.kernel.org/linux-mm/20250319193028.29514-1-raghavendra.kt@amd.com/ [5] MGLRU scanning for page promotion - https://lore.kernel.org/lkml/20250324220301.1273038-1-kinseyho@google.com/ [6] IBS base hot page promotion - https://lore.kernel.org/linux-mm/20250306054532.221138-4-bharata@amd.com/ [7] Unmapped page cache folio promotion patchset - https://lore.kernel.org/linux-mm/20250411221111.493193-1-gourry@gourry.net/ Bharata B Rao (1): mm: sched: Batch-migrate misplaced pages Gregory Price (1): migrate: implement migrate_misplaced_folio_batch include/linux/migrate.h | 6 ++++ include/linux/sched.h | 4 +++ init/init_task.c | 2 ++ kernel/sched/fair.c | 64 +++++++++++++++++++++++++++++++++++++++++ mm/memory.c | 44 ++++++++++++++-------------- mm/migrate.c | 31 ++++++++++++++++++++ 6 files changed, 130 insertions(+), 21 deletions(-) -- 2.34.1
Hi, Bharata, Bharata B Rao <bharata@amd.com> writes: > Hi, > > This is an attempt to convert the NUMA balancing to do batched > migration instead of migrating one folio at a time. The basic > idea is to collect (from hint fault handler) the folios to be > migrated in a list and batch-migrate them from task_work context. > More details about the specifics are present in patch 2/2. > > During LSFMM[1] and subsequent discussions in MM alignment calls[2], > it was suggested that separate migration threads to handle migration > or promotion request may be desirable. Existing NUMA balancing, hot > page promotion and other future promotion techniques could off-load > migration part to these threads. What is the expected benefit of the change? For code reuse, we can use migrate_misplaced_folio() or migrate_misplaced_folio_batch() in various promotion path. For workload latency influence, per my understanding, PTE scanning is much more serious than migration. Why not start from that? > Or if we manage to have a single > source of hotness truth like kpromoted[3], then that too can hand > over migration requests to the migration threads. I am envisaging > that different hotness sources like kmmscand[4], MGLRU[5], IBS[6] > and CXL HMU would push hot page info to kpromoted, which would > then isolate and push the folios to be promoted to the migrator > thread. > > As a first step, this is an attempt to batch and perform NUMAB > migrations in async manner. Separate migration threads aren't > yet implemented but I am using Gregory's patch[7] that provides > migrate_misplaced_folio_batch() API to do batch migration of > misplaced folios. > > Some points for discussion > -------------------------- > 1. To isolate the misplaced folios or not? > > To do batch migration, the misplaced folios need to be stored in > some manner. I thought isolating them and using the folio->lru > field to link them up would be the most straight-forward way. But > then there were concerns expressed about folios remaining isolated > for long until they get migrated. > > Or should we just maintain the PFNs instead of folios and > isolate them only just prior to migrating them? > > 2. Managing target_nid for misplaced pages > > NUMAB provides the accurate target_nid for each folio that is > detected as misplaced. However when we don't migrate the folio > right away, but instead want to batch and do asyn migration later, > then where do we keep track of target_nid for each folio? > > In this implementation, I am using last_cpupid field as it appeared > that this field could be reused (with some challenges mentioned > in 2/2) for isolated folios. This approach may be specific to NUMAB > but then each sub-system that hands over pages to the migrator thread > should also provide a target_nid and hence each sub-system should be > free to maintain and track the target_nid of folios that it has > isolated/batched for migration in its own specific manner. > > 3. How many folios to batch? > > Currently I have a fixed threshold for number of folios to batch. > It could be a sysctl to allow a setting between a min and max. It > could also be auto-tuned if required. > > The state of the patchset > ------------------------- > * Still raw and very lightly tested > * Just posted to serve as base for subsequent discussions > here and in MM alignment calls. > > References > ---------- > [1] LSFMM LWN summary - https://lwn.net/Articles/1016519/ > [2] MM alignment call summary - https://lore.kernel.org/linux-mm/263d7140-c343-e82e-b836-ec85c52b54eb@google.com/ > [3] kpromoted patchset - https://lore.kernel.org/linux-mm/20250306054532.221138-1-bharata@amd.com/ > [4] Kmmscand: PTE A bit scanning - https://lore.kernel.org/linux-mm/20250319193028.29514-1-raghavendra.kt@amd.com/ > [5] MGLRU scanning for page promotion - https://lore.kernel.org/lkml/20250324220301.1273038-1-kinseyho@google.com/ > [6] IBS base hot page promotion - https://lore.kernel.org/linux-mm/20250306054532.221138-4-bharata@amd.com/ > [7] Unmapped page cache folio promotion patchset - https://lore.kernel.org/linux-mm/20250411221111.493193-1-gourry@gourry.net/ > > Bharata B Rao (1): > mm: sched: Batch-migrate misplaced pages > > Gregory Price (1): > migrate: implement migrate_misplaced_folio_batch > > include/linux/migrate.h | 6 ++++ > include/linux/sched.h | 4 +++ > init/init_task.c | 2 ++ > kernel/sched/fair.c | 64 +++++++++++++++++++++++++++++++++++++++++ > mm/memory.c | 44 ++++++++++++++-------------- > mm/migrate.c | 31 ++++++++++++++++++++ > 6 files changed, 130 insertions(+), 21 deletions(-) --- Best Regards, Huang, Ying
On 26-May-25 2:16 PM, Huang, Ying wrote: > Hi, Bharata, > > Bharata B Rao <bharata@amd.com> writes: > >> Hi, >> >> This is an attempt to convert the NUMA balancing to do batched >> migration instead of migrating one folio at a time. The basic >> idea is to collect (from hint fault handler) the folios to be >> migrated in a list and batch-migrate them from task_work context. >> More details about the specifics are present in patch 2/2. >> >> During LSFMM[1] and subsequent discussions in MM alignment calls[2], >> it was suggested that separate migration threads to handle migration >> or promotion request may be desirable. Existing NUMA balancing, hot >> page promotion and other future promotion techniques could off-load >> migration part to these threads. > > What is the expected benefit of the change? Initially it is about cleanliness and separation of migration into its own thread/sub-system. > > For code reuse, we can use migrate_misplaced_folio() or > migrate_misplaced_folio_batch() in various promotion path. That's what I have done in this patchset at least. We thought we could go full length and off-load migration to its own thread. > > For workload latency influence, per my understanding, PTE scanning is > much more serious than migration. Why not start from that? Raghu's PTE A bit scanning is one effort towards that (Removing PTE scanning from task context. Regards, Bharata.
Bharata B Rao <bharata@amd.com> writes: > On 26-May-25 2:16 PM, Huang, Ying wrote: >> Hi, Bharata, >> Bharata B Rao <bharata@amd.com> writes: >> >>> Hi, >>> >>> This is an attempt to convert the NUMA balancing to do batched >>> migration instead of migrating one folio at a time. The basic >>> idea is to collect (from hint fault handler) the folios to be >>> migrated in a list and batch-migrate them from task_work context. >>> More details about the specifics are present in patch 2/2. >>> >>> During LSFMM[1] and subsequent discussions in MM alignment calls[2], >>> it was suggested that separate migration threads to handle migration >>> or promotion request may be desirable. Existing NUMA balancing, hot >>> page promotion and other future promotion techniques could off-load >>> migration part to these threads. >> What is the expected benefit of the change? > > Initially it is about cleanliness and separation of migration into its > own thread/sub-system. > >> For code reuse, we can use migrate_misplaced_folio() or >> migrate_misplaced_folio_batch() in various promotion path. > > That's what I have done in this patchset at least. We thought we could > go full length and off-load migration to its own thread. Even if we migrate pages in another thread, the migrated pages will be unmapped, copied, remapped during migrating. That is, the workload threads may be stalled to wait for migrating. So, we need to measure the real benefit firstly. >> For workload latency influence, per my understanding, PTE scanning >> is >> much more serious than migration. Why not start from that? > > Raghu's PTE A bit scanning is one effort towards that (Removing PTE > scanning from task context. --- Best Regards, Huang, Ying
Hi Bharata, On Wed, 21 May 2025 13:32:36 +0530 Bharata B Rao <bharata@amd.com> wrote: > Hi, > > This is an attempt to convert the NUMA balancing to do batched > migration instead of migrating one folio at a time. The basic > idea is to collect (from hint fault handler) the folios to be > migrated in a list and batch-migrate them from task_work context. > More details about the specifics are present in patch 2/2. > > During LSFMM[1] and subsequent discussions in MM alignment calls[2], > it was suggested that separate migration threads to handle migration > or promotion request may be desirable. Existing NUMA balancing, hot > page promotion and other future promotion techniques could off-load > migration part to these threads. Or if we manage to have a single > source of hotness truth like kpromoted[3], then that too can hand > over migration requests to the migration threads. I am envisaging > that different hotness sources like kmmscand[4], MGLRU[5], IBS[6] > and CXL HMU would push hot page info to kpromoted, which would > then isolate and push the folios to be promoted to the migrator > thread. I think (or, hope) it would also be not very worthless or rude to mention other existing and ongoing works that have potentials to serve for similar purpose or collaborate in future, here. DAMON is designed for a sort of multi-source access information handling. In LSFMM, I proposed[1] damon_report_access() interface for making it easier to be extended for more types of access information. Currenlty damon_report_access() is under early development. I think this has a potential to serve something similar to your single source goal. Also in LSFMM, I proposed damos_add_folio() for a case that callers want to utilize DAMON worker thread (kdamond) as an asynchronous memory management operations execution thread while using its other features such as [auto-tuned] quotas. I think this has a potential to serve something similar to your migration threads. I haven't started damos_add_folio() development yet, though. I remember we discussed about DAMON on mailing list and in LSFMM a bit, on your session. IIRC, you were also looking for a time to see if there is a chance to use DAMON in some way. Due to the technical issue, we were unable to discuss on the two new proposals on my LSFMM session, and it has been a bit while since our last discussion. So if you don't mind, I'd like to ask if you have some opinions or comments about these. [1] https://lwn.net/Articles/1016525/ Thanks, SJ [...]
Hi SJ, On 22-May-25 12:15 AM, SeongJae Park wrote: > Hi Bharata, > > On Wed, 21 May 2025 13:32:36 +0530 Bharata B Rao <bharata@amd.com> wrote: > >> Hi, >> >> This is an attempt to convert the NUMA balancing to do batched >> migration instead of migrating one folio at a time. The basic >> idea is to collect (from hint fault handler) the folios to be >> migrated in a list and batch-migrate them from task_work context. >> More details about the specifics are present in patch 2/2. >> >> During LSFMM[1] and subsequent discussions in MM alignment calls[2], >> it was suggested that separate migration threads to handle migration >> or promotion request may be desirable. Existing NUMA balancing, hot >> page promotion and other future promotion techniques could off-load >> migration part to these threads. Or if we manage to have a single >> source of hotness truth like kpromoted[3], then that too can hand >> over migration requests to the migration threads. I am envisaging >> that different hotness sources like kmmscand[4], MGLRU[5], IBS[6] >> and CXL HMU would push hot page info to kpromoted, which would >> then isolate and push the folios to be promoted to the migrator >> thread. > > I think (or, hope) it would also be not very worthless or rude to mention other > existing and ongoing works that have potentials to serve for similar purpose or > collaborate in future, here. > > DAMON is designed for a sort of multi-source access information handling. In > LSFMM, I proposed[1] damon_report_access() interface for making it easier to be > extended for more types of access information. Currenlty damon_report_access() > is under early development. I think this has a potential to serve something > similar to your single source goal. > > Also in LSFMM, I proposed damos_add_folio() for a case that callers want to > utilize DAMON worker thread (kdamond) as an asynchronous memory > management operations execution thread while using its other features such as > [auto-tuned] quotas. I think this has a potential to serve something similar > to your migration threads. I haven't started damos_add_folio() development > yet, though. > > I remember we discussed about DAMON on mailing list and in LSFMM a bit, on your > session. IIRC, you were also looking for a time to see if there is a chance to > use DAMON in some way. Due to the technical issue, we were unable to discuss > on the two new proposals on my LSFMM session, and it has been a bit while since > our last discussion. So if you don't mind, I'd like to ask if you have some > opinions or comments about these. > > [1] https://lwn.net/Articles/1016525/ Since this patchset was just about making the migration batched and async for NUMAB, I didn't mention DAMON as an alternative here. One of the concerns I always had about DAMON when it is considered as replacement for existing hot page migration is its current inability to gather and maintain hot page info at per-folio granularity. How much that eventually matters to the workloads has to be really seen. Regards, Bharata. Regards, Bharata.
On Mon, 26 May 2025 10:50:02 +0530 Bharata B Rao <bharata@amd.com> wrote: > Hi SJ, > > On 22-May-25 12:15 AM, SeongJae Park wrote: > > Hi Bharata, > > > > On Wed, 21 May 2025 13:32:36 +0530 Bharata B Rao <bharata@amd.com> wrote: > > > >> Hi, > >> > >> This is an attempt to convert the NUMA balancing to do batched > >> migration instead of migrating one folio at a time. The basic > >> idea is to collect (from hint fault handler) the folios to be > >> migrated in a list and batch-migrate them from task_work context. > >> More details about the specifics are present in patch 2/2. > >> > >> During LSFMM[1] and subsequent discussions in MM alignment calls[2], > >> it was suggested that separate migration threads to handle migration > >> or promotion request may be desirable. Existing NUMA balancing, hot > >> page promotion and other future promotion techniques could off-load > >> migration part to these threads. Or if we manage to have a single > >> source of hotness truth like kpromoted[3], then that too can hand > >> over migration requests to the migration threads. I am envisaging > >> that different hotness sources like kmmscand[4], MGLRU[5], IBS[6] > >> and CXL HMU would push hot page info to kpromoted, which would > >> then isolate and push the folios to be promoted to the migrator > >> thread. > > > > I think (or, hope) it would also be not very worthless or rude to mention other > > existing and ongoing works that have potentials to serve for similar purpose or > > collaborate in future, here. > > > > DAMON is designed for a sort of multi-source access information handling. In > > LSFMM, I proposed[1] damon_report_access() interface for making it easier to be > > extended for more types of access information. Currenlty damon_report_access() > > is under early development. I think this has a potential to serve something > > similar to your single source goal. > > > > Also in LSFMM, I proposed damos_add_folio() for a case that callers want to > > utilize DAMON worker thread (kdamond) as an asynchronous memory > > management operations execution thread while using its other features such as > > [auto-tuned] quotas. I think this has a potential to serve something similar > > to your migration threads. I haven't started damos_add_folio() development > > yet, though. > > > > I remember we discussed about DAMON on mailing list and in LSFMM a bit, on your > > session. IIRC, you were also looking for a time to see if there is a chance to > > use DAMON in some way. Due to the technical issue, we were unable to discuss > > on the two new proposals on my LSFMM session, and it has been a bit while since > > our last discussion. So if you don't mind, I'd like to ask if you have some > > opinions or comments about these. > > > > [1] https://lwn.net/Articles/1016525/ > > Since this patchset was just about making the migration batched and > async for NUMAB, I didn't mention DAMON as an alternative here. I was thinking a clarification like this could be useful for readers though, since you were mentioning the future work together. Thank you for clarifying. > > One of the concerns I always had about DAMON when it is considered as > replacement for existing hot page migration is its current inability to > gather and maintain hot page info at per-folio granularity. I think this is a very valid concern. But I don't think DAMON should be a _replacement_. Rather, I'm looking for a chance to make existing approaches help each other. For example, I recommend running DAMON-based memory tiering[1] together with the LRU-based demotion. I think there is no reason to discourage using it together with NUMAB-2 based promotion, if the folio granularity is a real issue. That is, still NUMAB-2 will do synchronous promotion, but DAMON will do it asynchronously, so the amount of synchronous promotions and its overhead will reduce. I didn't encourage using NUMB-2 based promotion together with DAMON-based memory tiering[1] not because I show a problem at such co-usage, but just because I found no clear benefit of that from my test setup. In theory, I think running those together makes sense. That said, we're also making efforts for overcoming the folio-granularity issue on DAMON side, too. We implemented page-level filters that motivated by SK hynix' test results, and developed monitoring intervals auto-tuning for overall monitoring results accuracy. We proposed damon_report_access() and damos_add_folios() as yet another opportunitis to better deal with the issue. I was curious about your opinion to damon_report_access() and damos_add_folios() for the reason. I understand that could be out of the scope of this patch series, though. > How much > that eventually matters to the workloads has to be really seen. Cannot agree more. Nonetheless, as mentioned abovely, my test setup[1] didn't show the problem. That said, I'm not really convinced with my test setup, and I don't think the test setup is good for verifying the problem. Hence I'm trying to make a better test setup for this. I'll share more of the new setup if I make some progress. I will also be more than happy to learn about other's test setup if they have a good one or suggestions. [1] https://lore.kernel.org/20250420194030.75838-1-sj@kernel.org Thanks, SJ [...]
On Wed, May 21, 2025 at 11:45:52AM -0700, SeongJae Park wrote: > Hi Bharata, > > On Wed, 21 May 2025 13:32:36 +0530 Bharata B Rao <bharata@amd.com> wrote: > > > Hi, > > > > This is an attempt to convert the NUMA balancing to do batched > > migration instead of migrating one folio at a time. The basic > > idea is to collect (from hint fault handler) the folios to be > > migrated in a list and batch-migrate them from task_work context. > > More details about the specifics are present in patch 2/2. > > > > During LSFMM[1] and subsequent discussions in MM alignment calls[2], > > it was suggested that separate migration threads to handle migration > > or promotion request may be desirable. Existing NUMA balancing, hot > > page promotion and other future promotion techniques could off-load > > migration part to these threads. Or if we manage to have a single > > source of hotness truth like kpromoted[3], then that too can hand > > over migration requests to the migration threads. I am envisaging > > that different hotness sources like kmmscand[4], MGLRU[5], IBS[6] > > and CXL HMU would push hot page info to kpromoted, which would > > then isolate and push the folios to be promoted to the migrator > > thread. > > I think (or, hope) it would also be not very worthless or rude to mention other > existing and ongoing works that have potentials to serve for similar purpose or > collaborate in future, here. > > DAMON is designed for a sort of multi-source access information handling. In > LSFMM, I proposed[1] damon_report_access() interface for making it easier to be > extended for more types of access information. Currenlty damon_report_access() > is under early development. I think this has a potential to serve something > similar to your single source goal. > It seems to me that DAMON might make use of the batch migration interface, so if you need any changes or extensions, it might be good for you (SJ) to take a look at that for us. ~Gregory
On Wed, 21 May 2025 23:08:16 -0400 Gregory Price <gourry@gourry.net> wrote: > On Wed, May 21, 2025 at 11:45:52AM -0700, SeongJae Park wrote: > > Hi Bharata, > > > > On Wed, 21 May 2025 13:32:36 +0530 Bharata B Rao <bharata@amd.com> wrote: > > > > > Hi, > > > > > > This is an attempt to convert the NUMA balancing to do batched > > > migration instead of migrating one folio at a time. The basic > > > idea is to collect (from hint fault handler) the folios to be > > > migrated in a list and batch-migrate them from task_work context. > > > More details about the specifics are present in patch 2/2. > > > > > > During LSFMM[1] and subsequent discussions in MM alignment calls[2], > > > it was suggested that separate migration threads to handle migration > > > or promotion request may be desirable. Existing NUMA balancing, hot > > > page promotion and other future promotion techniques could off-load > > > migration part to these threads. Or if we manage to have a single > > > source of hotness truth like kpromoted[3], then that too can hand > > > over migration requests to the migration threads. I am envisaging > > > that different hotness sources like kmmscand[4], MGLRU[5], IBS[6] > > > and CXL HMU would push hot page info to kpromoted, which would > > > then isolate and push the folios to be promoted to the migrator > > > thread. > > > > I think (or, hope) it would also be not very worthless or rude to mention other > > existing and ongoing works that have potentials to serve for similar purpose or > > collaborate in future, here. > > > > DAMON is designed for a sort of multi-source access information handling. In > > LSFMM, I proposed[1] damon_report_access() interface for making it easier to be > > extended for more types of access information. Currenlty damon_report_access() > > is under early development. I think this has a potential to serve something > > similar to your single source goal. > > > > It seems to me that DAMON might make use of the batch migration > interface, so if you need any changes or extensions, it might be good > for you (SJ) to take a look at that for us. I started this subthread not for batch migration but the long term goal. I took only a glance on the migration batching part, and I'm still trying to find time to take more deep look on batch migration. Nonetheless, yes, basically I believe DAMON and Bharata's works have great opportunities to collaborate and use each other in a very productive ways. I'm especially very intersted in kpromoted's AMD IBS code, and trying to make DAMON easier to be used for Bharata's works. For batch migration interface, though, to be honest I don't find very clear DAMON's usage of it, since DAMON does region-based sort of batched migration. Again, I took only a glance on migration batching part and gonna take more time to the details. Meanwhile, if you saw some opportunities, and if you don't mind, it would be very helpful if you can share your detailed view of the opportunity (how DAMON could be better by using the migration batching in what way?). Thanks, SJ > > ~Gregory
On Thu, May 22, 2025 at 09:30:23AM -0700, SeongJae Park wrote: > On Wed, 21 May 2025 23:08:16 -0400 Gregory Price <gourry@gourry.net> wrote: > > > > > It seems to me that DAMON might make use of the batch migration > > interface, so if you need any changes or extensions, it might be good > > for you (SJ) to take a look at that for us. > > For batch migration interface, though, to be honest I don't find very clear > DAMON's usage of it, since DAMON does region-based sort of batched migration. > Again, I took only a glance on migration batching part and gonna take more time > to the details. > DAMON would identify a set of PFNs or Folios to migrate, at some point, wouldn't it be beneficial to DAMON to simply re-use: int migrate_misplaced_folio_batch(struct list_head *folio_list, int node) If not, then why? That's why I mean by what would DAMON want out of such an interface. Not the async part, but the underlying migration functions. ~Gregory
On Thu, 22 May 2025 13:40:59 -0400 Gregory Price <gourry@gourry.net> wrote: > On Thu, May 22, 2025 at 09:30:23AM -0700, SeongJae Park wrote: > > On Wed, 21 May 2025 23:08:16 -0400 Gregory Price <gourry@gourry.net> wrote: > > > > > > > > It seems to me that DAMON might make use of the batch migration > > > interface, so if you need any changes or extensions, it might be good > > > for you (SJ) to take a look at that for us. > > > > For batch migration interface, though, to be honest I don't find very clear > > DAMON's usage of it, since DAMON does region-based sort of batched migration. > > Again, I took only a glance on migration batching part and gonna take more time > > to the details. > > > > DAMON would identify a set of PFNs or Folios to migrate, at some point, > wouldn't it be beneficial to DAMON to simply re-use: > > int migrate_misplaced_folio_batch(struct list_head *folio_list, int node) Good idea. Actually we implemnted DAMOS_MIGRATE_HOT and DAMOS_MIGRATE_COLD instead of DAMOS_PROMOTE and DAMOS_DEMOTE since we didn't sure the promotion path logic is somewhat everyone agreed upon. FYI, I'm planning to revisit the promotion path logic later (don't wait for me though ;) ). > > If not, then why? I'll need to look into the detail, but from a high level glance I think it is a good idea. > > That's why I mean by what would DAMON want out of such an interface. > Not the async part, but the underlying migration functions. Makes sense, thank you! Thanks, SJ [...]
On Wed, 21 May 2025 11:45:52 -0700 SeongJae Park <sj@kernel.org> wrote: [...] > I think (or, hope) it would also be not very worthless or rude to mention other > existing and ongoing works that have potentials to serve for similar purpose or > collaborate in future, here. > > DAMON is designed for a sort of multi-source access information handling. In > LSFMM, I proposed[1] damon_report_access() interface for making it easier to be > extended for more types of access information. Currenlty damon_report_access() > is under early development. I think this has a potential to serve something > similar to your single source goal. [...] I heard some people are feeling uncomfortable about patterns on my mails like this. I understand the pattern is that I suddenly replying to a thread saying "hey, by the way DAMON is ...", and I understand it bothers people when they wanted to discuss about something more than DAMON. I never intended to make others feel uncomfortable but was doing that with only good faith to make discussions be made with full information. But if you felt so, you felt so. I sincerely feel sorry if you felt so, and will try my best to not bother you next time. But, I'm a human and I cannot do something more than my best effort. I hence expect I will unintentionally continue making people upset. I think I migt be able to reduce such cases by explaining why and what I'm doing, and how you can avoid it. Yes, I might bothering you with exactly the pattern now, but let me do this hopefully as the last time, to reduce next recurrences. TL; DR: please briefly mention DAMON and optionally clarify DAMON discussion and/or clarifications are unwelcome for now, if you don't want to be bothered by DAMON. Why and What I'm Doing ====================== I sometimes find threads of works that seem related with DAMON. From such mails, I find opportunities to help the work using DAMON, shiny features of the work that DAMON could adopt, or whatever makes me believe so. Such mails sometimes contain explanations of such relations, and sometimes not. In some cases such relations description has some details that look important on the context but missed, outdated, or wrong. I believe I have a responsibility to add or fix those as a maintainer of DAMON for making Linux kernel healthier with discussions under full information, and so jump in. If there is no such relations description at all, I have no ability to know if they just don't know about DAMON, mistakenly didn't add the part, or want to ignore DAMON at the moment. Hence again I believe it is a responsibility of DAMON maintainer to tell about it, to help the original author and other reviewers' understanding. I think sometimes you didn't want to discuss or know such details of DAMON but I was jumping in and waste your time since I misread your intention. How You Can Prevent I Bothering You with DAMON ============================================== Please help me better understand your intentions. If you knwo DAMON and you feel I may find your work is related with DAMON, please take a moment to add a brief paragraph explaining it. If you don't want me adding more details that I believe worthy to be added there, or don't want to discuss in that detail of DAMON, please mention so. E.g., "this may have potential relations with DAMON, but that's out of the scope at the moment." I will also do my best to read implicit intention, but again, the best effort is the best effort and I cannot promise something I cannot do. Thanks, SJ [...]
© 2016 - 2025 Red Hat, Inc.