On Fri, 4 Mar 2022, David Hildenbrand wrote: > > In this context we can consider ZONE_DEVICE pages just like any other > pages that, although getting freed, are not returned to the buddy, but > instead are returned to another pool. So PAGE_FLAGS_CHECK_AT_PREP won't > apply and free_pages_prepare() won't apply. > > Another example would be hugetlb pages, that are returned to the hugetlb > pool, but not back to the buddy unless the huge page pool is shrunk. > > > So I feel like the underlying principle here is: we don't *care* if > PG_waiter is cleared when a page gets freed, because it will simply get > cleared by the next waker if it sticks around. I think we were focused on different issues here. I was focused on how it was redundant for those places to clear the bit, because it was going to get cleared anyway just after (in the buddy case). Whereas you are focused on how it doesn't matter at all whether it gets cleared when freeing. Both valid points. > > Then, I agree, we can just drop the comment regarding > PAGE_FLAGS_CHECK_AT_PREP and instead have something like Okay, the reference to PAGE_FLAGS_CHECK_AT_PREP in the commit message is good enough for me, no need to make a point of it in the code comment. > > > " > That's okay, it's a rare case and the next waker will just clear it. > Note that, depending on the page pool (buddy, ZONE_DEVICE, hugetlb), we > might clear the flag while freeing the page, however, this is not > required for correctness. > " Okay, v2 coming up: I've taken largely your wording (but not exactly). Thanks, Hugh
