The current approach to increasing CMA utilization introduced in
commit 16867664936e ("mm,page_alloc,cma: conditionally prefer cma
pageblocks for movable allocations") increases CMA utilization by
redirecting MIGRATE_MOVABLE allocations to a CMA region, when
greater than half of the free pages in a given zone are CMA pages.
The issue in this approach is that allocations with type
MIGRATE_MOVABLE can still succumb to pinning. To get around
this, one approach is to re-direct allocations to the CMA areas, that
are known not to be victims of pinning.
To this end, this series brings in __GFP_CMA, which we mark with
allocations that we know are safe to be redirected to a CMA area.
Heesub Shin (1):
cma: redirect page allocation to CMA
Vinayak Menon (1):
zram: allow zram to allocate CMA pages
drivers/block/zram/zram_drv.c | 5 +--
include/linux/gfp.h | 15 ++++++++
include/linux/highmem.h | 4 ++-
include/linux/mmzone.h | 4 +++
mm/page_alloc.c | 83 +++++++++++++++++++++++++++----------------
mm/zsmalloc.c | 4 +--
6 files changed, 79 insertions(+), 36 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
From: Vinayak Menon <[email protected]>
Though zram pages are movable, they aren't allowed to enter
MIGRATE_CMA pageblocks. zram is not seen to pin pages for
long which can cause an issue. Moreover allowing zram to
pick CMA pages can be helpful in cases seen where zram order
0 alloc fails when there are lots of free cma pages, resulting
in kswapd or direct reclaim not making enough progress.
Signed-off-by: Vinayak Menon <[email protected]>
Signed-off-by: Chris Goldsworthy <[email protected]>
---
drivers/block/zram/zram_drv.c | 5 +++--
mm/zsmalloc.c | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 9a1e6ee..4b6b16d 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1380,13 +1380,14 @@ static int __zram_bvec_write(struct zram *zram, struct bio_vec *bvec,
__GFP_KSWAPD_RECLAIM |
__GFP_NOWARN |
__GFP_HIGHMEM |
- __GFP_MOVABLE);
+ __GFP_MOVABLE |
+ __GFP_CMA);
if (!handle) {
zcomp_stream_put(zram->comp);
atomic64_inc(&zram->stats.writestall);
handle = zs_malloc(zram->mem_pool, comp_len,
GFP_NOIO | __GFP_HIGHMEM |
- __GFP_MOVABLE);
+ __GFP_MOVABLE | __GFP_CMA);
if (handle)
goto compress_again;
return -ENOMEM;
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index b03bee2..16ba318 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -351,7 +351,7 @@ static void destroy_cache(struct zs_pool *pool)
static unsigned long cache_alloc_handle(struct zs_pool *pool, gfp_t gfp)
{
return (unsigned long)kmem_cache_alloc(pool->handle_cachep,
- gfp & ~(__GFP_HIGHMEM|__GFP_MOVABLE));
+ gfp & ~(__GFP_HIGHMEM|__GFP_MOVABLE|__GFP_CMA));
}
static void cache_free_handle(struct zs_pool *pool, unsigned long handle)
@@ -362,7 +362,7 @@ static void cache_free_handle(struct zs_pool *pool, unsigned long handle)
static struct zspage *cache_alloc_zspage(struct zs_pool *pool, gfp_t flags)
{
return kmem_cache_alloc(pool->zspage_cachep,
- flags & ~(__GFP_HIGHMEM|__GFP_MOVABLE));
+ flags & ~(__GFP_HIGHMEM|__GFP_MOVABLE|__GFP_CMA));
}
static void cache_free_zspage(struct zs_pool *pool, struct zspage *zspage)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
On Mon, Nov 02, 2020 at 06:39:20AM -0800, Chris Goldsworthy wrote:
> The current approach to increasing CMA utilization introduced in
> commit 16867664936e ("mm,page_alloc,cma: conditionally prefer cma
> pageblocks for movable allocations") increases CMA utilization by
> redirecting MIGRATE_MOVABLE allocations to a CMA region, when
> greater than half of the free pages in a given zone are CMA pages.
> The issue in this approach is that allocations with type
> MIGRATE_MOVABLE can still succumb to pinning. To get around
> this, one approach is to re-direct allocations to the CMA areas, that
> are known not to be victims of pinning.
>
> To this end, this series brings in __GFP_CMA, which we mark with
> allocations that we know are safe to be redirected to a CMA area.
This feels backwards to me. What you're essentially saying is "Some
allocations marked with GFP_MOVABLE turn out not to be movable, so we're
going to add another GFP_REALLY_MOVABLE flag" instead of tracking down
which GFP_MOVABLE allocations aren't really movable.
On 02.11.20 15:44, Matthew Wilcox wrote:
> On Mon, Nov 02, 2020 at 06:39:20AM -0800, Chris Goldsworthy wrote:
>> The current approach to increasing CMA utilization introduced in
>> commit 16867664936e ("mm,page_alloc,cma: conditionally prefer cma
>> pageblocks for movable allocations") increases CMA utilization by
>> redirecting MIGRATE_MOVABLE allocations to a CMA region, when
>> greater than half of the free pages in a given zone are CMA pages.
>> The issue in this approach is that allocations with type
>> MIGRATE_MOVABLE can still succumb to pinning. To get around
>> this, one approach is to re-direct allocations to the CMA areas, that
>> are known not to be victims of pinning.
>>
>> To this end, this series brings in __GFP_CMA, which we mark with
>> allocations that we know are safe to be redirected to a CMA area.
>
> This feels backwards to me. What you're essentially saying is "Some
> allocations marked with GFP_MOVABLE turn out not to be movable, so we're
> going to add another GFP_REALLY_MOVABLE flag" instead of tracking down
> which GFP_MOVABLE allocations aren't really movable.
Right, this just sounds wrong. We have the exact same issues with
long-term pinnings on ZONE_MOVABLE. We have known issues with short-term
pinnings and movable allocations (e.g., when a process dies) that should
be tackled instead.
This is just trying to work around the original issue.
Nacked-by: David Hildenbrand <[email protected]>
--
Thanks,
David / dhildenb
On Mon 02-11-20 14:44:49, Matthew Wilcox wrote:
> On Mon, Nov 02, 2020 at 06:39:20AM -0800, Chris Goldsworthy wrote:
> > The current approach to increasing CMA utilization introduced in
> > commit 16867664936e ("mm,page_alloc,cma: conditionally prefer cma
> > pageblocks for movable allocations") increases CMA utilization by
> > redirecting MIGRATE_MOVABLE allocations to a CMA region, when
> > greater than half of the free pages in a given zone are CMA pages.
> > The issue in this approach is that allocations with type
> > MIGRATE_MOVABLE can still succumb to pinning. To get around
> > this, one approach is to re-direct allocations to the CMA areas, that
> > are known not to be victims of pinning.
> >
> > To this end, this series brings in __GFP_CMA, which we mark with
> > allocations that we know are safe to be redirected to a CMA area.
>
> This feels backwards to me. What you're essentially saying is "Some
> allocations marked with GFP_MOVABLE turn out not to be movable, so we're
> going to add another GFP_REALLY_MOVABLE flag" instead of tracking down
> which GFP_MOVABLE allocations aren't really movable.
Absolutely agreed. What is even worse the proposed approach doesn't
really add any new guarantee. Just look at how the new flag is used for
any anonymous page and that is a subject to a long term pinning as well.
So in the end a new and confusing gfp flag is proposed that doesn't
really help with the underlying problem.
Nacked-by: Michal Hocko <[email protected]>
--
Michal Hocko
SUSE Labs