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

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

[Xishi Qiu]

MIGRATE_HIGHATOMIC page blocks are reserved for an atomic
high-order allocation, so use it as late as possible.

Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
---
 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

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

[Xishi Qiu]

MIGRATE_HIGHATOMIC page blocks are reserved for an atomic
high-order allocation, so use it as late as possible.

Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
---
 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


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[RFC][PATCH 2/2] mm: unreserve highatomic pageblock if direct reclaim failed

[Xishi Qiu]

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 <qiuxishi@huawei.com>
---
 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

[RFC][PATCH 2/2] mm: unreserve highatomic pageblock if direct reclaim failed

[Xishi Qiu]

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 <qiuxishi@huawei.com>
---
 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


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

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

[Michal Hocko]

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 <qiuxishi@huawei.com>
> ---
>  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

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

[Michal Hocko]

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 <qiuxishi@huawei.com>
> ---
>  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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

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

[Xishi Qiu]

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 <qiuxishi@huawei.com>
>> ---
>>  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
>>
> 

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

[Xishi Qiu]

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 <qiuxishi@huawei.com>
>> ---
>>  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
>>
> 



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

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

[Michal Hocko]

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

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

[Michal Hocko]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>