linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Haiqiang Gong (龚海强)" <Haiqiang.Gong@mediatek.com>
To: Baolin Wang <baolin.wang@linux.alibaba.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "Mike Zhang (张伟伟)" <Mike.Zhang@mediatek.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"AngeloGioacchino Del Regno"
	<angelogioacchino.delregno@collabora.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>
Subject: 回复: [PATCH] mm/compaction: add check mechanism to avoid cma alloc fail
Date: Wed, 24 Jan 2024 01:41:40 +0000	[thread overview]
Message-ID: <JH0PR03MB880917DB01BA88CBCF709CE3947B2@JH0PR03MB8809.apcprd03.prod.outlook.com> (raw)
In-Reply-To: <8583a965-82ae-42fe-b22a-e84ddda11ae5@linux.alibaba.com>

[-- Attachment #1: Type: text/plain, Size: 4703 bytes --]

> Why the CMA memory can not be migrated? Could you describe in more

> detail the reasons for the CMA memory migration failure?

When allocate for cma memory by module, the memory used by system in the

cma buffer will be migrate outside the cma buffer. If the refcount of the

current page in cma buffer is greater than the mapcount, the migrate will

fail.

The page that failed to be migrate was not originally in the cma buffer,

but was migrate in cma buffer after the kernel compaction.

After this memory is kcompacted and placed in the cma buffer, under

certain special conditions, the refcount may be greater than the mapcount

(ex:the current page is being used by fs), and then migrate will fail.


发件人: Baolin Wang <baolin.wang@linux.alibaba.com>
发送时间: 2024年1月22日 14:59
收件人: Haiqiang Gong (龚海强) <Haiqiang.Gong@mediatek.com>; linux-kernel@vger.kernel.org
抄送: Mike Zhang (张伟伟) <Mike.Zhang@mediatek.com>; Andrew Morton <akpm@linux-foundation.org>; Matthias Brugger <matthias.bgg@gmail.com>; AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>; linux-mm@kvack.org; linux-arm-kernel@lists.infradead.org; linux-mediatek@lists.infradead.org
主题: Re: [PATCH] mm/compaction: add check mechanism to avoid cma alloc fail

External email : Please do not click links or open attachments until you have verified the sender or the content.





On 1/22/2024 10:23 AM, Haiqiang Gong wrote:

> cma alloc may fail when we doing cma alloc/free test on kernel 5.10/5.15.



Do you have a real use case for the cma alloc issue? And have you tried

it on the new kernel?



> We found that the next memory cannot be migrated because of the alloc of

> fs as next backtrace:

> __alloc_pages_nodemask

> pagecache_get_page

> grow_dev_page

> __getblk_gfp

> ext4_sb_breadahead_unmovable

> __ext4_get_inode_loc

> __ext4_iget

> ext4_lookup

> __lookup_slow

> walk_component

> path_lookupat

> filename_lookup

> vfs_statx

> This kind of unmovable memory is not placed in the cma buffer when kernel

> memory alloc but is migrated in by kcompactd when the kernel migration.

> It will cause memory can't be migrate when cma alloc.



Why the CMA memory can not be migrated? Could you describe in more

detail the reasons for the CMA memory migration failure?



> Add check mechanism in the compaction_alloc() where kcompaced alloc for

> memory. Will return NULL and give up this memory migration if the

> allocated memory is in the cma buffer and the memory is unmovable.

>

> Signed-off-by: Haiqiang Gong <Haiqiang.Gong@mediatek.com<mailto:Haiqiang.Gong@mediatek.com>>

> ---

>   mm/compaction.c | 38 ++++++++++++++++++++++++++++++++++++++

>   1 file changed, 38 insertions(+)

>

> diff --git a/mm/compaction.c b/mm/compaction.c

> index 27ada42924d5..29c0661adc22 100644

> --- a/mm/compaction.c

> +++ b/mm/compaction.c

> @@ -25,6 +25,11 @@

>   #include <linux/psi.h>

>   #include "internal.h"

>

> +#ifdef CONFIG_CMA

> +#include <linux/cma.h>

> +#include "cma.h"

> +#endif

> +

>   #ifdef CONFIG_COMPACTION

>   /*

>    * Fragmentation score check interval for proactive compaction purposes.

> @@ -1758,6 +1763,33 @@ static void isolate_freepages(struct compact_control *cc)

>   split_map_pages(freelist);

>   }

>

> +#ifdef CONFIG_CMA

> +static bool is_in_cma_range(struct folio *folio)

> +{

> +int i;

> +unsigned long pfn = 0;

> +struct page *page = folio_page(folio, 0);

> +

> +pfn = page_to_pfn(page);

> +for (i = 0; i < cma_area_count; i++) {

> +struct cma *cma = &cma_areas[i];

> +

> +if (cma->base_pfn <= pfn && (cma->base_pfn + cma->count) > pfn)

> +return true;

> +}

> +

> +return false;

> +}

> +

> +static bool forbid_move_to_cma_range(struct folio *src, struct folio *dst)

> +{

> +if (folio_mapping(src) && is_in_cma_range(dst))

> +return true;

> +

> +return false;

> +}

> +#endif

> +

>   /*

>    * This is a migrate-callback that "allocates" freepages by taking pages

>    * from the isolated freelists in the block we are migrating to.

> @@ -1775,6 +1807,12 @@ static struct folio *compaction_alloc(struct folio *src, unsigned long data)

>   }

>

>   dst = list_entry(cc->freepages.next, struct folio, lru);

> +#ifdef CONFIG_CMA

> +if (forbid_move_to_cma_range(src, dst)) {

> +pr_notice("kcompactd: could not move non-cma memory to cma buffer\n");

> +return NULL;

> +}

> +#endif

>   list_del(&dst->lru);

>   cc->nr_freepages--;

>

[-- Attachment #2: Type: text/html, Size: 15443 bytes --]

  reply	other threads:[~2024-01-24  1:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-22  2:23 Haiqiang Gong
2024-01-22  3:31 ` Matthew Wilcox
2024-01-23 12:14   ` 回复: " Haiqiang Gong (龚海强)
2024-01-24  7:20   ` Haiqiang Gong (龚海强)
2024-01-24 18:40     ` Matthew Wilcox
2024-01-27 11:03       ` Haiqiang Gong (龚海强)
2024-01-27 16:23         ` Matthew Wilcox
2024-01-22  6:59 ` Baolin Wang
2024-01-24  1:41   ` Haiqiang Gong (龚海强) [this message]
2024-01-24  7:37   ` Haiqiang Gong (龚海强)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=JH0PR03MB880917DB01BA88CBCF709CE3947B2@JH0PR03MB8809.apcprd03.prod.outlook.com \
    --to=haiqiang.gong@mediatek.com \
    --cc=Mike.Zhang@mediatek.com \
    --cc=akpm@linux-foundation.org \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=matthias.bgg@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox