Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx> writes: > On 11/14/2023 9:12 AM, Huang, Ying wrote: >> David Hildenbrand <david@xxxxxxxxxx> writes: >> >>> On 13.11.23 11:45, Baolin Wang wrote: >>>> Currently, the file pages already support large folio, and supporting for >>>> anonymous pages is also under discussion[1]. Moreover, the numa balancing >>>> code are converted to use a folio by previous thread[2], and the migrate_pages >>>> function also already supports the large folio migration. >>>> So now I did not see any reason to continue restricting NUMA >>>> balancing for >>>> large folio. >>> >>> I recall John wanted to look into that. CCing him. >>> >>> I'll note that the "head page mapcount" heuristic to detect sharers will >>> now strike on the PTE path and make us believe that a large folios is >>> exclusive, although it isn't. >> Even 4k folio may be shared by multiple processes/threads. So, numa >> balancing uses a multi-stage node selection algorithm (mostly >> implemented in should_numa_migrate_memory()) to identify shared folios. >> I think that the algorithm needs to be adjusted for PTE mapped large >> folio for shared folios. > > Not sure I get you here. In should_numa_migrate_memory(), it will use > last CPU id, last PID and group numa faults to determine if this page > can be migrated to the target node. So for large folio, a precise > folio sharers check can make the numa faults of a group more accurate, > which is enough for should_numa_migrate_memory() to make a decision? A large folio that is mapped by multiple process may be accessed by one remote NUMA node, so we still want to migrate it. A large folio that is mapped by one process but accessed by multiple threads on multiple NUMA node may be not migrated. > Could you provide a more detailed description of the algorithm you > would like to change for large folio? Thanks. I haven't thought about that thoroughly. So, please evaluate the algorithm by yourself. For example, the 2 sub-pages of a shared PTE-mapped large folio may be accessed together by a task. This may cause the folio be migrated wrongly. One possible solution is to restore all other PTE mappings of the large folio in do_numa_page() as the first step. This resembles the PMD-mapped THP behavior. >> And, as a performance improvement patch, some performance data needs to > > Do you have some benchmark recommendation? I know the the autonuma can > not support large folio now. There are autonuma-benchmark, and specjbb is used by someone before. >> be provided. And, the effect of shared folio detection needs to be >> tested too -- Best Regards, Huang, Ying
