Messages in this thread | | | Date | Tue, 6 Dec 2016 13:53:28 +0000 | From | Mel Gorman <> | Subject | Re: [PATCH 2/2] mm: page_alloc: High-order per-cpu page allocator v5 |
| |
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
| |