On Mon, Aug 19, 2024 at 8:33 PM Barry Song <21cnbao@xxxxxxxxx> wrote: > > On Mon, Aug 19, 2024 at 8:28 PM David Hildenbrand <david@xxxxxxxxxx> wrote: > > > > On 18.08.24 09:58, Barry Song wrote: > > > Hi Andrew, David, Usama, > > > > > > I'm attempting to rebase this series on top of Usama's > > > [PATCH v3 0/6] mm: split underutilized THPs[1] > > > > > > However, I feel it is impossible and we might be tackling things > > > in the wrong order. > > > > Is just the ordering suboptimal (which can/will get resolved one way or > > the other), or is there something fundamental that will make this series > > here "impossible"? > > i think it is just the ordering suboptimal. Ideally, mTHP counters can go > first, then the new partially_mapped feature will rebase on top of > mTHP counters. Sorry, please allow me to ramble a bit more. The nr_split_deferred counter is straightforward and simple without the partially_mapped feature. Each time we enter split_list, we increment by 1, and when we leave, we decrement by 1. With the new partially_mapped feature, we can enter split_list without actually being partially_mapped. If the MTHP counter series is processed first, the partially_mapped series can handle all cases while properly clearing and setting the partially_mapped flag. These flag operations need to be handled carefully. Currently, I notice that Usama's series is clearing the flag unconditionally in all cases. In simple terms, mTHP counters are just a counting mechanism that doesn't introduce new features. However, partially_mapped is a new feature. A better approach might be to handle the counters first, then ensure that the new feature doesn't break the counter. > > > > > -- > > Cheers, > > > > David / dhildenb Thanks Barry
