* [RFC 1/2] Try to use HighAtomic if try to alloc umovable page that order is not 0
2017-09-26 8:46 [RFC 0/2] Use HighAtomic against long-term fragmentation Hui Zhu
@ 2017-09-26 8:46 ` Hui Zhu
2017-09-26 10:47 ` Michal Hocko
2017-09-26 8:46 ` [RFC 2/2] Change limit of HighAtomic from 1% to 10% Hui Zhu
2017-09-26 9:51 ` [RFC 0/2] Use HighAtomic against long-term fragmentation Mel Gorman
2 siblings, 1 reply; 7+ messages in thread
From: Hui Zhu @ 2017-09-26 8:46 UTC (permalink / raw)
To: akpm, mhocko, vbabka, mgorman, hillf.zj, linux-mm, linux-kernel
Cc: teawater, Hui Zhu
The page add a new condition to let gfp_to_alloc_flags return
alloc_flags with ALLOC_HARDER if the order is not 0 and migratetype is
MIGRATE_UNMOVABLE.
Then alloc umovable page that order is not 0 will try to use HighAtomic.
Signed-off-by: Hui Zhu <zhuhui@xiaomi.com>
---
mm/page_alloc.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c841af8..b54e94a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3642,7 +3642,7 @@ static void wake_all_kswapds(unsigned int order, const struct alloc_context *ac)
}
static inline unsigned int
-gfp_to_alloc_flags(gfp_t gfp_mask)
+gfp_to_alloc_flags(gfp_t gfp_mask, int order, int migratetype)
{
unsigned int alloc_flags = ALLOC_WMARK_MIN | ALLOC_CPUSET;
@@ -3671,6 +3671,8 @@ static void wake_all_kswapds(unsigned int order, const struct alloc_context *ac)
alloc_flags &= ~ALLOC_CPUSET;
} else if (unlikely(rt_task(current)) && !in_interrupt())
alloc_flags |= ALLOC_HARDER;
+ else if (order > 0 && migratetype == MIGRATE_UNMOVABLE)
+ alloc_flags |= ALLOC_HARDER;
#ifdef CONFIG_CMA
if (gfpflags_to_migratetype(gfp_mask) == MIGRATE_MOVABLE)
@@ -3903,7 +3905,7 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
* kswapd needs to be woken up, and to avoid the cost of setting up
* alloc_flags precisely. So we do that now.
*/
- alloc_flags = gfp_to_alloc_flags(gfp_mask);
+ alloc_flags = gfp_to_alloc_flags(gfp_mask, order, ac->migratetype);
/*
* We need to recalculate the starting point for the zonelist iterator
--
1.9.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>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [RFC 1/2] Try to use HighAtomic if try to alloc umovable page that order is not 0
2017-09-26 8:46 ` [RFC 1/2] Try to use HighAtomic if try to alloc umovable page that order is not 0 Hui Zhu
@ 2017-09-26 10:47 ` Michal Hocko
0 siblings, 0 replies; 7+ messages in thread
From: Michal Hocko @ 2017-09-26 10:47 UTC (permalink / raw)
To: Hui Zhu; +Cc: akpm, vbabka, mgorman, hillf.zj, linux-mm, linux-kernel, teawater
On Tue 26-09-17 16:46:43, Hui Zhu wrote:
> The page add a new condition to let gfp_to_alloc_flags return
> alloc_flags with ALLOC_HARDER if the order is not 0 and migratetype is
> MIGRATE_UNMOVABLE.
Apart from what Mel has already said this changelog is really lacking
the crucial information. It says what but it doesn't explain why we need
this and why it is safe to do. What kind of workload will benefit from
this change and how much. What about those users who are relying on high
atomic reserves currently and now would need to share it with other
users.
Without knowing all that background and from a quick look this looks
like a very crude hack to me, to be completely honest.
> Then alloc umovable page that order is not 0 will try to use HighAtomic.
>
> Signed-off-by: Hui Zhu <zhuhui@xiaomi.com>
> ---
> mm/page_alloc.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c841af8..b54e94a 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3642,7 +3642,7 @@ static void wake_all_kswapds(unsigned int order, const struct alloc_context *ac)
> }
>
> static inline unsigned int
> -gfp_to_alloc_flags(gfp_t gfp_mask)
> +gfp_to_alloc_flags(gfp_t gfp_mask, int order, int migratetype)
> {
> unsigned int alloc_flags = ALLOC_WMARK_MIN | ALLOC_CPUSET;
>
> @@ -3671,6 +3671,8 @@ static void wake_all_kswapds(unsigned int order, const struct alloc_context *ac)
> alloc_flags &= ~ALLOC_CPUSET;
> } else if (unlikely(rt_task(current)) && !in_interrupt())
> alloc_flags |= ALLOC_HARDER;
> + else if (order > 0 && migratetype == MIGRATE_UNMOVABLE)
> + alloc_flags |= ALLOC_HARDER;
>
> #ifdef CONFIG_CMA
> if (gfpflags_to_migratetype(gfp_mask) == MIGRATE_MOVABLE)
> @@ -3903,7 +3905,7 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
> * kswapd needs to be woken up, and to avoid the cost of setting up
> * alloc_flags precisely. So we do that now.
> */
> - alloc_flags = gfp_to_alloc_flags(gfp_mask);
> + alloc_flags = gfp_to_alloc_flags(gfp_mask, order, ac->migratetype);
>
> /*
> * We need to recalculate the starting point for the zonelist iterator
> --
> 1.9.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>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [RFC 2/2] Change limit of HighAtomic from 1% to 10%
2017-09-26 8:46 [RFC 0/2] Use HighAtomic against long-term fragmentation Hui Zhu
2017-09-26 8:46 ` [RFC 1/2] Try to use HighAtomic if try to alloc umovable page that order is not 0 Hui Zhu
@ 2017-09-26 8:46 ` Hui Zhu
2017-09-26 9:51 ` [RFC 0/2] Use HighAtomic against long-term fragmentation Mel Gorman
2 siblings, 0 replies; 7+ messages in thread
From: Hui Zhu @ 2017-09-26 8:46 UTC (permalink / raw)
To: akpm, mhocko, vbabka, mgorman, hillf.zj, linux-mm, linux-kernel
Cc: teawater, Hui Zhu
After "Try to use HighAtomic if try to alloc umovable page that order
is not 0". The result is still not very well because the the limit of
HighAtomic make kernel cannot reserve more pageblock to HighAtomic.
The patch change max_managed from 1% to 10% make HighAtomic can get more
pageblocks.
Signed-off-by: Hui Zhu <zhuhui@xiaomi.com>
---
mm/page_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b54e94a..9322458 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2101,7 +2101,7 @@ static void reserve_highatomic_pageblock(struct page *page, struct zone *zone,
* Limit the number reserved to 1 pageblock or roughly 1% of a zone.
* Check is race-prone but harmless.
*/
- max_managed = (zone->managed_pages / 100) + pageblock_nr_pages;
+ max_managed = (zone->managed_pages / 10) + pageblock_nr_pages;
if (zone->nr_reserved_highatomic >= max_managed)
return;
--
1.9.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>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC 0/2] Use HighAtomic against long-term fragmentation
2017-09-26 8:46 [RFC 0/2] Use HighAtomic against long-term fragmentation Hui Zhu
2017-09-26 8:46 ` [RFC 1/2] Try to use HighAtomic if try to alloc umovable page that order is not 0 Hui Zhu
2017-09-26 8:46 ` [RFC 2/2] Change limit of HighAtomic from 1% to 10% Hui Zhu
@ 2017-09-26 9:51 ` Mel Gorman
2017-09-26 10:04 ` Hui Zhu
2 siblings, 1 reply; 7+ messages in thread
From: Mel Gorman @ 2017-09-26 9:51 UTC (permalink / raw)
To: Hui Zhu; +Cc: akpm, mhocko, vbabka, hillf.zj, linux-mm, linux-kernel, teawater
On Tue, Sep 26, 2017 at 04:46:42PM +0800, Hui Zhu wrote:
> Current HighAtomic just to handle the high atomic page alloc.
> But I found that use it handle the normal unmovable continuous page
> alloc will help to against long-term fragmentation.
>
This is not wise. High-order atomic allocations do not always have a
smooth recovery path such as network drivers with large MTUs that have no
choice but to drop the traffic and hope for a retransmit. That's why they
have the highatomic reserve. If the reserve is used for normal unmovable
allocations then allocation requests that could have waited for reclaim
may cause high-order atomic allocations to fail. Changing it may allow
improve latencies in some limited cases while causing functional failures
in others. If there is a special case where there are a large number of
other high-order allocations then I would suggest increasing min_free_kbytes
instead as a workaround.
--
Mel Gorman
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>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC 0/2] Use HighAtomic against long-term fragmentation
2017-09-26 9:51 ` [RFC 0/2] Use HighAtomic against long-term fragmentation Mel Gorman
@ 2017-09-26 10:04 ` Hui Zhu
2017-09-26 10:43 ` Mel Gorman
0 siblings, 1 reply; 7+ messages in thread
From: Hui Zhu @ 2017-09-26 10:04 UTC (permalink / raw)
To: Mel Gorman
Cc: Hui Zhu, Andrew Morton, Michal Hocko, Vlastimil Babka, hillf.zj,
Linux Memory Management List, linux-kernel
2017-09-26 17:51 GMT+08:00 Mel Gorman <mgorman@techsingularity.net>:
> On Tue, Sep 26, 2017 at 04:46:42PM +0800, Hui Zhu wrote:
>> Current HighAtomic just to handle the high atomic page alloc.
>> But I found that use it handle the normal unmovable continuous page
>> alloc will help to against long-term fragmentation.
>>
>
> This is not wise. High-order atomic allocations do not always have a
> smooth recovery path such as network drivers with large MTUs that have no
> choice but to drop the traffic and hope for a retransmit. That's why they
> have the highatomic reserve. If the reserve is used for normal unmovable
> allocations then allocation requests that could have waited for reclaim
> may cause high-order atomic allocations to fail. Changing it may allow
> improve latencies in some limited cases while causing functional failures
> in others. If there is a special case where there are a large number of
> other high-order allocations then I would suggest increasing min_free_kbytes
> instead as a workaround.
I think let 0 order unmovable page alloc and other order unmovable pages
alloc use different migrate types will help against long-term
fragmentation.
Do you think kernel can add a special migrate type for big than 0 order
unmovable pages alloc?
Thanks,
Hui
>
> --
> Mel Gorman
> 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>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC 0/2] Use HighAtomic against long-term fragmentation
2017-09-26 10:04 ` Hui Zhu
@ 2017-09-26 10:43 ` Mel Gorman
0 siblings, 0 replies; 7+ messages in thread
From: Mel Gorman @ 2017-09-26 10:43 UTC (permalink / raw)
To: Hui Zhu
Cc: Hui Zhu, Andrew Morton, Michal Hocko, Vlastimil Babka, hillf.zj,
Linux Memory Management List, linux-kernel
On Tue, Sep 26, 2017 at 06:04:04PM +0800, Hui Zhu wrote:
> 2017-09-26 17:51 GMT+08:00 Mel Gorman <mgorman@techsingularity.net>:
> > On Tue, Sep 26, 2017 at 04:46:42PM +0800, Hui Zhu wrote:
> >> Current HighAtomic just to handle the high atomic page alloc.
> >> But I found that use it handle the normal unmovable continuous page
> >> alloc will help to against long-term fragmentation.
> >>
> >
> > This is not wise. High-order atomic allocations do not always have a
> > smooth recovery path such as network drivers with large MTUs that have no
> > choice but to drop the traffic and hope for a retransmit. That's why they
> > have the highatomic reserve. If the reserve is used for normal unmovable
> > allocations then allocation requests that could have waited for reclaim
> > may cause high-order atomic allocations to fail. Changing it may allow
> > improve latencies in some limited cases while causing functional failures
> > in others. If there is a special case where there are a large number of
> > other high-order allocations then I would suggest increasing min_free_kbytes
> > instead as a workaround.
>
> I think let 0 order unmovable page alloc and other order unmovable pages
> alloc use different migrate types will help against long-term
> fragmentation.
>
That can already happen through the migratetype fallback lists.
> Do you think kernel can add a special migrate type for big than 0 order
> unmovable pages alloc?
>
Technically, yes but the barrier to entry will be high as you'll have to
explain carefully why it is necessary including information on why order-0
pages cannot be used, back it up with data showing what is improved as a
result and justify why potentially forcing normal workloads to reclaim due
to being unable to use the high-order reserve is ok. If it's a limitation
of a specific driver then it'll be asked why that driver does not have a
dedicated pool (which is functionally similar to having a dedicated reserve).
--
Mel Gorman
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>
^ permalink raw reply [flat|nested] 7+ messages in thread