[LTP] [PATCH] syscalls/setrlimit06: lower RLIMIT_CPU parameters

[Li Wang]

On Tue, Feb 11, 2020 at 8:10 PM Jan Stancek <jstancek@redhat.com> wrote:

>
>
> ----- Original Message -----
> > On Tue, Feb 11, 2020 at 6:52 PM Jan Stancek <jstancek@redhat.com> wrote:
> >
> > >
> > >
> > > ----- Original Message -----
> > > > On Mon, Feb 10, 2020 at 8:47 PM Jan Stancek <jstancek@redhat.com>
> wrote:
> > > >
> > > > > Lower the parameters so that test completes faster where possible.
> > > > >
> > > > > This also increases alarm timer slightly, which in combination with
> > > > > lower RLIMIT_CPU aims to avoid false positives in environments with
> > > > > high steal time, where it can take multiple of wall clock seconds
> > > > > to spend single second on a cpu.
> > > > >
> > > >
> > > > This patch could reduce the test failure possibility, but I'm afraid
> it
> > > > can't fix the problem radically, because with `stress -c 20' to
> overload
> > > an
> > > > s390x system(2cpus) in the background then setrlimit06(patched) still
> > > > easily gets failed:
> > > >     setrlimit06.c:98: FAIL: Got only SIGXCPU after reaching both
> limit
> > > >
> > > > Another way I can think of is to raise the priority before its
> running,
> > > not
> > > > sure if that will disturb the original test but from my test, it
> always
> > > > gets a pass even with too much overload.
> > >
> > > Is this in addition to my patch? Because on its own I don't see how
> this
> > > will help when load is coming from different guests.
> > >
> >
> > Yes, this is only solving for itself loads. Besides the high steal time,
> > that's another reason I guess it causes the same failure, so do you think
> > it makes sense to merge two methods together?
>
> For now I'd go with just original patch. Until there is parallel test
> execution,
> there shouldn't be any local load during this test.
>

Ok sure. Let's apply the original first, then keep watching the status in
the next testing.

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