Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1594090 > unrolled thread

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

Started byXishi Qiu <qiuxishi@huawei.com>
First post2017-03-07 11:40 +0100
Last post2017-03-07 11:50 +0100
Articles 5 — 2 participants

Back to article view | Back to linux.kernel

Contents

  [RFC][PATCH 1/2] mm: use MIGRATE_HIGHATOMIC as late as possible Xishi Qiu <qiuxishi@huawei.com> - 2017-03-07 11:40 +0100
    Re: [RFC][PATCH 1/2] mm: use MIGRATE_HIGHATOMIC as late as possible Michal Hocko <mhocko@kernel.org> - 2017-03-07 11:50 +0100
      Re: [RFC][PATCH 1/2] mm: use MIGRATE_HIGHATOMIC as late as possible Xishi Qiu <qiuxishi@huawei.com> - 2017-03-07 12:10 +0100
        Re: [RFC][PATCH 1/2] mm: use MIGRATE_HIGHATOMIC as late as possible Michal Hocko <mhocko@kernel.org> - 2017-03-07 15:00 +0100
    [RFC][PATCH 2/2] mm: unreserve highatomic pageblock if direct reclaim  failed Xishi Qiu <qiuxishi@huawei.com> - 2017-03-07 11:50 +0100

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

FromXishi Qiu <qiuxishi@huawei.com>
Date2017-03-07 11:40 +0100
Subject[RFC][PATCH 1/2] mm: use MIGRATE_HIGHATOMIC as late as possible
Message-ID<tikH7-6ao-1@gated-at.bofh.it>
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

[toc] | [next] | [standalone]

#1594102

FromMichal Hocko <mhocko@kernel.org>
Date2017-03-07 11:50 +0100
Message-ID<tikQO-6fF-11@gated-at.bofh.it>
In reply to#1594090
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

[toc] | [prev] | [next] | [standalone]

#1594130

FromXishi Qiu <qiuxishi@huawei.com>
Date2017-03-07 12:10 +0100
Message-ID<tilab-6G6-43@gated-at.bofh.it>
In reply to#1594102
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
>>
>

[toc] | [prev] | [next] | [standalone]

#1594250

FromMichal Hocko <mhocko@kernel.org>
Date2017-03-07 15:00 +0100
Message-ID<tinOG-8fM-11@gated-at.bofh.it>
In reply to#1594130
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

[toc] | [prev] | [next] | [standalone]

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

FromXishi Qiu <qiuxishi@huawei.com>
Date2017-03-07 11:50 +0100
Subject[RFC][PATCH 2/2] mm: unreserve highatomic pageblock if direct reclaim failed
Message-ID<tikQO-6fF-21@gated-at.bofh.it>
In reply to#1594090
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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web