On Tue, Dec 06, 2016 at 11:43:45AM +0900, Joonsoo Kim wrote: > > actually clear at all it's an unfair situation, particularly given that the > > vanilla code is also unfair -- the vanilla code can artifically preserve > > MIGRATE_UNMOVABLE without any clear indication that it is a universal win. > > The only deciding factor there was a fault-intensive workload would mask > > overhead of the page allocator due to page zeroing cost which UNMOVABLE > > allocations may or may not require. Even that is vague considering that > > page-table allocations are zeroing even if many kernel allocations are not. > > "Vanilla works like that" doesn't seem to be reasonable to justify > this change. Vanilla code works with three lists and it now become > six lists and each list can have different size of page. We need to > think that previous approach will also work fine with current one. I > think that there is a problem although it's not permanent and would be > minor. However, it's better to fix it when it is found. > This is going in circles. I prototyped the modification which increases the per-cpu structure slightly and will evaluate. It takes about a day to run through the full set of tests. If it causes no harm, I'll release another version. -- 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>