[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <190cd3842bc0776611c73a439e49ba57c86849d1.camel@surriel.com>
Date: Tue, 16 Sep 2025 23:30:20 -0400
From: Rik van Riel <riel@...riel.com>
To: Frank van der Linden <fvdl@...gle.com>, akpm@...ux-foundation.org,
muchun.song@...ux.dev, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Cc: hannes@...xchg.org, david@...hat.com, roman.gushchin@...ux.dev
Subject: Re: [RFC PATCH 06/12] mm/cma: define and act on CMA_BALANCE flag
On Mon, 2025-09-15 at 19:51 +0000, Frank van der Linden wrote:
>
> @@ -851,7 +862,10 @@ int __init
> cma_declare_contiguous_multi(phys_addr_t total_size,
> list_for_each_safe(mp, next, &ranges) {
> mlp = list_entry(mp, struct cma_init_memrange,
> list);
> list_del(mp);
> - list_insert_sorted(&final_ranges, mlp, basecmp);
> + if (flags & CMA_BALANCE)
> + list_insert_sorted(&final_ranges, mlp,
> revbasecmp);
> + else
> + list_insert_sorted(&final_ranges, mlp,
> basecmp);
> sizesum += mlp->size;
> if (sizesum >= total_size)
> break;
Wait, what is this supposed to do when presented
with a mix of CMA_BALANCE and !CMA_BALANCE ranges?
I can't convince myself this would always keep
the CMA_BALANCE range near the top of the list,
and the others near the bottom.
Also, does the regular compaction code pay any
attention to the order of this list?
I have the feeling I am overlooking something big
in how this patch is supposed to work, but I am
not sure what that would be...
> @@ -866,7 +880,12 @@ int __init
> cma_declare_contiguous_multi(phys_addr_t total_size,
> list_for_each(mp, &final_ranges) {
> mlp = list_entry(mp, struct cma_init_memrange,
> list);
> size = min(sizeleft, mlp->size);
> - if (memblock_reserve(mlp->base, size)) {
> + if (flags & CMA_BALANCE)
> + start = (mlp->base + mlp->size - size);
> + else
> + start = mlp->base;
> +
> + if (memblock_reserve(start, size)) {
> /*
> * Unexpected error. Could go on to
> * the next one, but just abort to
>
--
All Rights Reversed.
Powered by blists - more mailing lists