From: Cyril Hrubis <chrubis@suse.cz>
To: Li Wang <liwang@redhat.com>
Cc: LTP List <ltp@lists.linux.it>
Subject: Re: [LTP] [RFC PATCH] fallocate05: increase the fallocate and defallocate size
Date: Fri, 24 Sep 2021 11:33:32 +0200 [thread overview]
Message-ID: <YU2bbLCJg2PorGI+@yuki> (raw)
In-Reply-To: <CAEemH2fRGX50RAgdAYJMW6FXX33FZG6kH=ygCQSGO6PHAi-S8g@mail.gmail.com>
Hi!
> > FYI I've tried to run syscalls on a VM with 256MB RAM just to see what
> > explodes and it looks like futex_cmp_requeue01 fails as well because we
> > don't have enough memory to fork 1000 processes. I guess that we really
> > need an API for at least rough scaling for the number of processes we
> > can run based on free memory. With that we could finally fix the
> > msgstress testcases as well.
> >
>
> +1 Sounds good.
>
> [Cc Fang Ping]
>
> Btw, AFAIK, pifang@ is working on an SUT ability(io, memory, ..) evaluation
> before running the test, then set test parameters intelligently according
> to the
> lite benchmark result. This will definitely help make a proper runtest file
> for LTP,
> but I'm not sure if he plans to integrate it in LTP internally.
>
> I will talk to him to learn more details.
This is a complex problem, but for now I guess that putting the logic in
the test library would be easiest solution, that allows the tests at
least skip subset of scenarios.
In the long term I guess that the logic can be put into runltp-ng but I
do not think that we can make it work anytime soon. At least this would
require definition of some kind of (JSON based) API that would explain
the test parameters to the testrunner.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2021-09-24 9:33 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-17 10:46 [LTP] [RFC PATCH] fallocate05: increase the fallocate and defallocate size Li Wang
2021-09-07 2:40 ` Li Wang
2021-09-07 2:40 ` Li Wang
2021-09-07 8:00 ` Jan Stancek
2021-09-07 8:00 ` Jan Stancek
2021-09-08 1:21 ` Li Wang
2021-09-08 1:21 ` Li Wang
2021-09-21 20:33 ` Ralph Siemsen
2021-09-22 5:03 ` Li Wang
2021-09-22 8:21 ` Cyril Hrubis
2021-09-22 9:53 ` Li Wang
2021-09-22 9:56 ` Cyril Hrubis
2021-09-22 10:34 ` Li Wang
2021-09-22 14:32 ` Cyril Hrubis
2021-09-22 16:52 ` Ralph Siemsen
2021-09-23 3:00 ` Li Wang
2021-09-23 6:29 ` Li Wang
2021-09-23 13:09 ` Cyril Hrubis
2021-09-24 4:27 ` Li Wang
2021-09-23 14:33 ` Cyril Hrubis
2021-09-24 1:49 ` Ralph Siemsen
2021-09-24 4:18 ` Li Wang
2021-09-24 15:11 ` Ralph Siemsen
2021-09-24 18:26 ` Cyril Hrubis
2021-09-24 20:26 ` Ralph Siemsen
2021-09-25 2:16 ` Ralph Siemsen
2021-09-26 7:17 ` Li Wang
2021-09-26 7:40 ` Li Wang
2021-09-26 7:39 ` Li Wang
2021-09-27 1:37 ` Ralph Siemsen
2021-09-24 6:49 ` Li Wang
2021-09-24 9:33 ` Cyril Hrubis [this message]
2021-09-23 6:39 ` Li Wang
2021-09-23 13:10 ` Cyril Hrubis
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=YU2bbLCJg2PorGI+@yuki \
--to=chrubis@suse.cz \
--cc=liwang@redhat.com \
--cc=ltp@lists.linux.it \
/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