Linux Test Project
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Wei Gao <wegao@suse.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v1] min_free_kbytes: Handle transient memory drops in check_monitor
Date: Tue, 26 May 2026 16:10:54 +0200	[thread overview]
Message-ID: <20260526141054.GA175193@pevik> (raw)
In-Reply-To: <20260526083650.14036-1-wegao@suse.com>

Hi Wei,

> High memory pressure can cause MemFree to temporarily drop below the
> min_free_kbytes threshold before the kernel reclaimer can catch up.
> This results in intermittent test failures, particularly observed on
> openQA aarch64 machines.

> Implement a 1-second grace period with exponential backoff polling
> (from 1ms up to 512ms) in check_monitor() to allow the kernel time to
> reclaim memory.

> Also the global 'end' flag is reset for multi-iteration
> support (-i).
IMHO this is not needed. Is it just wrong AI hint or you really spot it's
needed?

> Signed-off-by: Wei Gao <wegao@suse.com>
> ---
>  .../kernel/mem/tunable/min_free_kbytes.c      | 36 +++++++++++++------
>  1 file changed, 26 insertions(+), 10 deletions(-)

> diff --git a/testcases/kernel/mem/tunable/min_free_kbytes.c b/testcases/kernel/mem/tunable/min_free_kbytes.c
> index a62e4ae9d..59ba6a9e1 100644
> --- a/testcases/kernel/mem/tunable/min_free_kbytes.c
> +++ b/testcases/kernel/mem/tunable/min_free_kbytes.c
> @@ -1,6 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0-or-later
>  /*
> - * Copyright (c) Linux Test Project, 2012-2025
> + * Copyright (c) Linux Test Project, 2012-2026
>   * Copyright (C) 2012-2017  Red Hat, Inc.
>   */

> @@ -53,6 +53,8 @@ static void min_free_kbytes_test(void)
>  	int pid, status;
>  	struct sigaction sa;

> +	end = 0;
Why I think it's not needed? Here you're in the parent. But the value is changed
only in child (forked process), they run in a separate memory spaces (change in
child is not visible for the parent).

In patch without it + updated commit message you may add:
Reviewed-by: Petr Vorel <pvorel@suse.cz>

> +
>  	sa.sa_handler = sighandler;
>  	if (sigemptyset(&sa.sa_mask) < 0)
>  		tst_brk(TBROK | TERRNO, "sigemptyset");
> @@ -140,14 +142,13 @@ static void test_tune(unsigned long overcommit_policy)
>  		} else {
>  			if (WIFEXITED(status)) {
>  				if (WEXITSTATUS(status) != 0) {
> -					tst_res(TFAIL, "child unexpectedly "
> -						 "failed: %d", status);
> +					tst_res(TFAIL, "child unexpectedly failed: %d",
> +						status);
>  				}
>  			} else if (!WIFSIGNALED(status) ||
>  				   WTERMSIG(status) != SIGKILL) {
> -				tst_res(TFAIL,
> -					 "child unexpectedly failed: %d",
> -					 status);
> +				tst_res(TFAIL, "child unexpectedly failed: %d",
> +					status);
>  			}
Unrelated cleanup, but thanks.

>  		}
>  	}
> @@ -183,18 +184,33 @@ static void check_monitor(void)
>  {
>  	unsigned long tune;
>  	unsigned long memfree;
> +	int i;

>  	while (!end) {
>  		memfree = SAFE_READ_MEMINFO("MemFree:");
>  		tune = TST_SYS_CONF_LONG_GET(MIN_FREE_KBYTES);

>  		if (memfree < tune) {
> -			tst_res(TINFO, "MemFree is %lu kB, "
> -				 "min_free_kbytes is %lu kB", memfree, tune);
> -			tst_res(TFAIL, "MemFree < min_free_kbytes");
> +			/*
> +			 * Give it some time to reclaim. The kernel should keep
> +			 * MemFree above min_free_kbytes, but transient drops
> +			 * are possible under high pressure.
> +			 */
> +			for (i = 1; i < 1024; i *= 2) {
> +				usleep(i * 1000);
> +				memfree = SAFE_READ_MEMINFO("MemFree:");
> +				if (memfree >= tune)
> +					break;
> +			}
> +
> +			if (memfree < tune) {
> +				tst_res(TINFO, "MemFree is %lu kB, min_free_kbytes is %lu kB",
> +					memfree, tune);
> +				tst_res(TFAIL, "MemFree < min_free_kbytes");
> +			}
>  		}

> -		sleep(2);
> +		usleep(100000);
>  	}
>  }

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2026-05-26 14:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-26  8:36 [LTP] [PATCH v1] min_free_kbytes: Handle transient memory drops in check_monitor Wei Gao via ltp
2026-05-26 14:10 ` Petr Vorel [this message]
2026-05-27  5:08   ` Wei Gao via ltp
2026-05-26 14:14 ` Petr Vorel
2026-05-26 15:29 ` [LTP] " linuxtestproject.agent

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=20260526141054.GA175193@pevik \
    --to=pvorel@suse.cz \
    --cc=ltp@lists.linux.it \
    --cc=wegao@suse.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