Mike Kravetz <mike.kravetz@xxxxxxxxxx> writes: > On 01/12/23 08:09, Huang, Ying wrote: >> Hi, Mike, >> >> Mike Kravetz <mike.kravetz@xxxxxxxxxx> writes: >> >> > On 01/10/23 17:53, Mike Kravetz wrote: >> >> Just saw the following easily reproducible issue on next-20230110. Have not >> >> verified it is related to/caused by this series, but it looks suspicious. >> > >> > Verified this is caused by the series, >> > >> > 734cbddcfe72 migrate_pages: organize stats with struct migrate_pages_stats >> > to >> > 323b933ba062 migrate_pages: batch flushing TLB >> > >> > in linux-next. >> >> Thanks for reporting. >> >> I tried this yesterday (next-20230111), but failed to reproduce it. Can >> you share your kernel config? Is there any other setup needed? > > Config file is attached. Thanks! > Are you writing a REALLY big value to nr_hugepages? By REALLY big I > mean a value that is impossible to fulfill. This will result in > successful hugetlb allocations until __alloc_pages starts to fail. At > this point we will be stressing compaction/migration trying to find more > contiguous pages. > > Not sure if it matters, but I am running on a 2 node VM. The 2 nodes > may be important as the hugetlb allocation code will try a little harder > alternating between nodes that may perhaps stress compaction/migration > more. Tried again on a 2-node machine. Still cannot reproduce it. >> BTW: can you bisect to one specific commit which causes the bug in the >> series? > > I should have some time to isolate in the next day or so. Thanks! Best Regards, Huang, Ying
