mm: use MIGRATE_HIGHATOMIC as late as possible
Subsystems (2)
RFC PATCH 1/2 mm: use MIGRATE_HIGHATOMIC as late as possible
MIGRATE_HIGHATOMIC page blocks are reserved for an atomic high-order allocation, so use it as late as possible.
--- mm/page_alloc.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
mm/page_alloc.c +2 -4
@@ -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)
Signature · 1 line
1.8.3.1
RFC PATCH 2/2 mm: unreserve highatomic pageblock if direct reclaim failed
If direct reclaim failed, unreserve highatomic pageblock immediately is better than unreserve in should_reclaim_retry(). We may get page in next try rather than reclaim-compact-reclaim-compact...
--- mm/page_alloc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
mm/page_alloc.c +2 -1
@@ -3421,7 +3421,8 @@ void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, const char *fmt, ...)bool drained = false; *did_some_progress =__perform_reclaim (gfp_mask, order, ac); -if (unlikely (!(*did_some_progress))) +if (unlikely (!(*did_some_progress) + && !unreserve_highatomic_pageblock (ac, false)))return NULL ; retry:
Signature · 8 lines
1.8.3.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 2 lines · Xishi Qiu
MIGRATE_HIGHATOMICpage 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).
Quoted 29 lines
Signed-off-by Xishi Qiu <[email protected]>--- mm/page_alloc.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)mm/page_alloc.c +2
-4@@ -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)Signature · 1 line
1.8.3.1
Signature · 8 lines
Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 8 lines · Michal Hocko
Quoted 2 lines · Xishi Qiu
MIGRATE_HIGHATOMICpage 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
Quoted 30 lines
Quoted 29 lines
Signed-off-by Xishi Qiu <[email protected]>--- mm/page_alloc.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)mm/page_alloc.c +2
-4@@ -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)Signature · 1 line
1.8.3.1
Quoted 11 lines · Xishi Qiu
Quoted 8 lines · Michal Hocko
Quoted 2 lines · Xishi Qiu
MIGRATE_HIGHATOMICpage 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).
Quoted 5 lines
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?
Please make sure you measure your changes under different workloads and present numbers in the changelog when you are touch such a subtle things like memory reserves. Ideas that might sound they make sense can turn out to behave differently in the real life.
Signature · 8 lines
Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>