[LTP] [REGRESSION] lkft ltp for 6763a36

[Li Wang]

On Tue, Jun 21, 2022 at 4:56 PM Richard Palethorpe <rpalethorpe@suse.de>
wrote:

> Hello,
>
> Joerg Vehlow <lkml@jv-coder.de> writes:
>
> > Hi Jan,
> >
> > Am 6/21/2022 um 9:22 AM schrieb Jan Stancek:
> >> On Tue, Jun 21, 2022 at 9:15 AM Joerg Vehlow <lkml@jv-coder.de> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Am 6/17/2022 um 3:17 AM schrieb lkft@linaro.org:
> >>>> * qemu_i386, ltp-fs-tests
> >>>>   - read_all_proc
> >>> I've seen this test fail a lot, has anyone ever tried to analyze it? I
> >>> was unable to reproduce the problem when running the test in isolation.
> >>
> >> I see it hit timeouts too (read_all_sys as well). I think it needs
> >> runtime restored to 5minutes as well, atm. it has 30s.
> > Didn't think about that, but at least for the failures I've seen, this
> > is not the reason. The message printed by the test is "Test timeout 5
> > minutes exceeded."
> >
> > Joerg
>
> The main issue with read_all is that it also acts as a stress
> test. Reading some files in proc and sys is very resource intensive
> (e.g. due to lock contention) and varies depending on what state the
> system is in. On some systems this test will take a long time. Also
> there are some files which have to be filtered from the test. This
> varies by system as well.
>

Does it make sense to have a lite version of read_all_sys?
which may only go through files sequentially or under slight stress.

With regard to this stressful read_all, I guess we can put into a dedicated
set and run separately in stress testing.

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20220621/df05670b/attachment.htm>