[LTP] [PATCH v2] mem/min_free_kbytes: Add grace period for memory reclaim

Petr Vorel pvorel@suse.cz
Fri May 29 18:07:08 CEST 2026


Hi all,

> > @@ -140,14 +140,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);

> We do have tst_strstatus().

+1, I fixed this as a separate change:
https://github.com/linux-test-project/ltp/commit/d81526f7da5645a04d6e03e557d3c829b67b3c57

> >  				}
> >  			} else if (!WIFSIGNALED(status) ||
> >  				   WTERMSIG(status) != SIGKILL) {
> > -				tst_res(TFAIL,
> > -					 "child unexpectedly failed: %d",
> > -					 status);
> > +				tst_res(TFAIL, "child unexpectedly failed: %d",
> > +					status);
> >  			}
> >  		}
> >  	}
> > @@ -183,18 +182,32 @@ 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(TFAIL, "MemFree %lu kB < min_free_kbytes %lu kB",
> > +					memfree, tune);
> > +			}
> >  		}

> Looks good.

> Reviewed-by: Cyril Hrubis <chrubis@suse.cz>

> I think that we also want to change the test so that the monitor is
> started and stopped for each testcase with a specific value we set the
> min_free_kbytes to. Running it asynchronously like this may mean that we
> will be looking for a wrong value for the second if we are unlucky. But
> that can be done later on.

@Wei Unfortunately this does not help on the current stable kernels (at least
not on 7.0.10 on Tumbleweed. We discussed it with Vlastimil Babka and Cyril
Hrubis and the conclusion  is to start with running the monitor synchronously
with each subtestcase and making sure MemFree is big enough before we start the
monitor and the process that creates memory stress.
Also, please rebase when doing changes.

Kind regards,
Petr


More information about the ltp mailing list