From: "Lucas A. M. Magalhaes" <lamm@linux.ibm.com>
To: Florian Weimer <fweimer@redhat.com>,
Stefan Liebler via Libc-alpha <libc-alpha@sourceware.org>
Cc: Stefan Liebler <stli@linux.ibm.com>
Subject: Re: [PATCH] Loosen the limits of time/tst-cpuclock1.
Date: Mon, 31 Aug 2020 09:57:11 -0300 [thread overview]
Message-ID: <159887863153.2808979.8243416548539150947@localhost.localdomain> (raw)
In-Reply-To: <87d03brm12.fsf@oldenburg2.str.redhat.com>
Quoting Florian Weimer via Libc-alpha (2020-08-28 09:29:45)
> * Stefan Liebler via Libc-alpha:
>
> > Starting with the commit 04deeaa9ea74b0679dfc9d9155a37b6425f19a9f "Fix
> > time/tst-cpuclock1 intermitent failures" (2020-07-11), this test fails
> > quite often on s390x/s390 with one/multiple of those: "before - after"
> > / "nanosleep time" / "dead - after" ourside reasonable range.
>
> How much value do these cpuclock tests actually have? Maybe we should
> just remove them, given that their test objective is so difficult to
> model in current execution environments.
AFAICS this test was moved from rt/ to time/ when the clock_* functions
were migrated to libc.so. IMHO this test lost it's purpose during this
migration. I can see why it was needed on rt/, with strict time
measures, but on time/ it's just testing clock_* API. I this case I don't
see a downside to flex the time requirements.
A good thing to add for this test is a comment on the beginning stating
the purpose of it. :)
>
> Maybe we could measure clock discontinuities on the CPU-burning thread
> and detect CPU stealing this way. But I'm not sure if this would be
> worth it.
What we want to achieve with this?
---
Lucas A. M. Magalhães
next prev parent reply other threads:[~2020-08-31 12:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-28 8:58 Stefan Liebler
2020-08-28 12:29 ` Florian Weimer
2020-08-31 12:57 ` Lucas A. M. Magalhaes [this message]
2020-08-31 12:59 ` Florian Weimer
2020-09-02 16:10 ` Stefan Liebler
2020-09-21 11:28 ` Florian Weimer
2020-09-29 13:53 ` Lucas A. M. Magalhaes
2020-09-29 14:01 ` Adhemerval Zanella
2020-09-29 17:22 ` Carlos O'Donell
2020-09-30 11:48 ` Adhemerval Zanella
2020-10-19 14:48 ` Stefan Liebler
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=159887863153.2808979.8243416548539150947@localhost.localdomain \
--to=lamm@linux.ibm.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=stli@linux.ibm.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).