On Fri, Dec 09, 2016 at 10:37:53AM +0100, Vlastimil Babka wrote: > In __free_one_page() we do the buddy merging arithmetics on "page/buddy index", > which is just the lower MAX_ORDER bits of pfn. The operations we do that affect > the higher bits are bitwise AND and subtraction (in that order), where the > final result will be the same with the higher bits left unmasked, as long as > these bits are equal for both buddies - which must be true by the definition of > a buddy. Ok, other than the kbuild warning, both patchs look ok. I expect the benefit is marginal but every little bit helps. > > We can therefore use pfn's directly instead of "index" and skip the zeroing of > >MAX_ORDER bits. This can help a bit by itself, although compiler might be > smart enough already. It also helps the next patch to avoid page_to_pfn() for > memory hole checks. > I expect this benefit only applies to a few archiectures and won't be visible on x86 but it still makes sense so for both patches; Acked-by: Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> As a slight aside, I recently spotted that one of the largest overhead in the bulk free path was in the page_is_buddy() checks so pretty much anything that helps that is welcome. -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>