> 2. Another approach. Let's avoid a branch in free_one_page if we don't enable > CONFIG_MEMORY_ISOLATION? It's simpler/less-churning/more accurate/removing > unnecessary codes compared to 1. > > index 7e208f0..35c0e82 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -683,8 +683,12 @@ static void free_one_page(struct zone *zone, struct page *page, int order, > zone->pages_scanned = 0; > > __free_one_page(page, zone, order, migratetype); > +#ifdef CONFIG_MEMORY_ISOLATION > if (unlikely(migratetype != MIGRATE_ISOLATE)) > __mod_zone_freepage_state(zone, 1 << order, migratetype); > +#else > + __mod_zone_freepage_state(zone, 1 << order, migratetype); > +#endif > spin_unlock(&zone->lock); > } > > So I will > > Acked-by: Minchan Kim <minchan@xxxxxxxxxx> > > Then, will send 2 as follow-up patch soon if anyone doesn't oppose. I agree. I guess we can remove this branch completely from free page fast path. However your patch is good first step. -- 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>