2017-03-07 10:37:43

by Xishi Qiu

Subject: [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.

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

2017-03-07 10:47:41

by Xishi Qiu

Subject: [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...

Signed-off-by: Xishi Qiu <[email protected]>
---
mm/page_alloc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 2331840..2bd19d0 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -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:
--
1.8.3.1

2017-03-07 10:49:32

by Michal Hocko

Subject: Re: [RFC][PATCH 1/2] mm: use MIGRATE_HIGHATOMIC as late as possible

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).

> 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
>

--
Michal Hocko
SUSE Labs

2017-03-07 11:04:31

by Xishi Qiu

Subject: Re: [RFC][PATCH 1/2] mm: use MIGRATE_HIGHATOMIC as late as possible

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
>>
>

2017-03-07 13:58:35

by Michal Hocko

Subject: Re: [RFC][PATCH 1/2] mm: use MIGRATE_HIGHATOMIC as late as possible

On Tue 07-03-17 19:03:39, Xishi Qiu wrote:
> 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?

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.
--
Michal Hocko
SUSE Labs