Re: [LTP] [REGRESSION] lkft ltp for cea142b

From: Li Wang <liwang@redhat.com>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: Martin Doucha <martin.doucha@suse.com>,
	lkft@linaro.org, lkft-triage@lists.linaro.org,
	LTP List <ltp@lists.linux.it>
Subject: Re: [LTP] [REGRESSION] lkft ltp for cea142b
Date: Mon, 19 Sep 2022 16:39:35 +0800	[thread overview]
Message-ID: <CAEemH2f=BQ3bdfKgPQzSYZjkTAx5mptptA31ToSTWzu-GQ1ovw@mail.gmail.com> (raw)
In-Reply-To: <YygoFpOWW4Cuh2BB@yuki>

[-- Attachment #1.1: Type: text/plain, Size: 1103 bytes --]

On Mon, Sep 19, 2022 at 4:26 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > > tst_pollute_memory() consume time is proportional to the amount of
> > > free RAM, it is hard to find one fixed value of max_runtime to fit all
> test
> > > platforms.
> > >
> > > From my experience, if you limited this test only run with small
> > > machine (e.g. RAM <= 32G), that performs well with whatever
> > > bare metal or VM, no timeout ever.
> > >
> >
> > Btw, we did that by setting a test filter before LTP running, also we
> could
> > add a field .max_mem_avail to tst_test struct for achieving that, but not
> > sure if it's worth doing that at this moment.
>
> The proper solution will be adding a separate timeouts for setup/cleanup
> and limiting the setup runtime to something sensible, but that is
>

Separate timeouts for setup/cleanup will break the integrity of
setting functions, my concern is that if tst_pollute_memory stopped
in uncompleted, the main test part is meaningless, right?

Or, I may misunderstand you here.

> something for the next development cycle.
>

+1

-- 
Regards,
Li Wang

[-- Attachment #1.2: Type: text/html, Size: 2210 bytes --]

[-- Attachment #2: Type: text/plain, Size: 60 bytes --]

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