linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: liuqiqi@kylinos.cn
To: akpm@linux-foundation.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm:fix duplicate accounting of free pages in should_reclaim_retry()
Date: Mon, 25 Aug 2025 15:05:05 +0800	[thread overview]
Message-ID: <20250825070505.407367-1-liuqiqi@kylinos.cn> (raw)

Duplicate accounting of free pages in should_reclaim_retry() effects:
The number of retry in the __alloc_pages_slowpath() function has increased.
The execution time of the kswapd process has increased.

static inline struct page * 
__alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
                                                struct alloc_context *ac)
{
	......
retry:
	/*
	 * Deal with possible cpuset update races or zonelist updates to avoid
	 * infinite retries.
	 */
	......
        if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags,
                                 did_some_progress > 0, &no_progress_loops))
                goto retry;

The test program: continuously allocates 1k-sized memory through kmalloc(); 
counts the number of retry and the execution time of the kswapd process;
the test results also confirm this.

> Thanks. Does this have any significant runtime effects?

> In the zone_reclaimable_pages() function, if the page counts for
> NR_ZONE_INACTIVE_FILE, NR_ZONE_ACTIVE_FILE, NR_ZONE_INACTIVE_ANON,
> and NR_ZONE_ACTIVE_ANON are all zero,
> the function returns the number of free pages as the result.
>
> In this case, when should_reclaim_retry() calculates reclaimable pages,
> it will inadvertently double-count the free pages in its accounting.
>
> static inline bool
> should_reclaim_retry(gfp_t gfp_mask, unsigned order,
>                      struct alloc_context *ac, int alloc_flags,
>                      bool did_some_progress, int *no_progress_loops)
> {
>         ...
>                 available = reclaimable = zone_reclaimable_pages(zone);
>                 available += zone_page_state_snapshot(zone, NR_FREE_PAGES);

https://lore.kernel.org/all/20250817120016.8dcc091c5b7114d6993a29ae@linux-foundation.org/

---
Best Regards


             reply	other threads:[~2025-08-25  7:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-25  7:05 liuqiqi [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-08-12  7:02 liuqiqi
2025-08-17 19:00 ` Andrew Morton
2025-08-18  2:39 ` Ye Liu
2025-09-15 13:25 ` Chris Mason

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=20250825070505.407367-1-liuqiqi@kylinos.cn \
    --to=liuqiqi@kylinos.cn \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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