On 2017/3/7 18:47, Michal Hocko wrote: > On Tue 07-03-17 18:33:53, Xishi Qiu wrote: >> MIGRATE_HIGHATOMIC page blocks are reserved for an atomic >> high-order allocation, so use it as late as possible. > > Why is this better? Are you seeing any problem which this patch > resolves? In other words the patch description should explain why not > only what (that is usually clear from looking at the diff). >
Hi Michal, I have not see any problem yet, I think if we reserve more high order pageblocks, the more success rate we will get when meet an atomic high-order allocation, right? Thanks, Xishi Qiu >> Signed-off-by: Xishi Qiu <[email protected]> >> --- >> mm/page_alloc.c | 6 ++---- >> 1 file changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index 40d79a6..2331840 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -2714,14 +2714,12 @@ struct page *rmqueue(struct zone *preferred_zone, >> spin_lock_irqsave(&zone->lock, flags); >> >> do { >> - page = NULL; >> - if (alloc_flags & ALLOC_HARDER) { >> + page = __rmqueue(zone, order, migratetype); >> + if (!page && alloc_flags & ALLOC_HARDER) { >> page = __rmqueue_smallest(zone, order, >> MIGRATE_HIGHATOMIC); >> if (page) >> trace_mm_page_alloc_zone_locked(page, order, >> migratetype); >> } >> - if (!page) >> - page = __rmqueue(zone, order, migratetype); >> } while (page && check_new_pages(page, order)); >> spin_unlock(&zone->lock); >> if (!page) >> -- >> 1.8.3.1 >> >
