On 12/09/2016 06:26 PM, Mel Gorman wrote: > 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> Thanks! > 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. Interesting, the function shouldn't be doing really much on x86 without debug config options? We might try further optimize the zone equivalence checks, perhaps? - try caching page_zone_id(page) through whole merging, and only obtain it freshly for buddy candidate - mark arches/configurations sane enough that they have no zone boundary within MAX_ORDER, and skip these checks there. I assume most, if not all x86 would fall here? Somewhat analogically to page_valid_within(). -- 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>