From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
Adhemerval Zanella <azanella@linux.vnet.ibm.com>
Subject: Re: [PATCH] PowerPC: Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV
Date: Thu, 04 Sep 2014 17:39:00 -0000 [thread overview]
Message-ID: <alpine.DEB.1.10.1409041824170.27075@tp.orcam.me.uk> (raw)
In-Reply-To: <CAFULd4YFTWPrC8Gbr9AHewzpXiGGGHOjOXMv+a9B_yOO8SgJYg@mail.gmail.com>
On Wed, 3 Sep 2014, Uros Bizjak wrote:
> > So I think the default timeout that's used for really quick tests should
> > be extended a bit. I propose a factor of 2, just not to make it too
> > excessive, at least for the beginning (maybe it'll have to be higher
> > eventually).
>
> Or you can just lower the iteration count as I have to do for alpha.
Thanks for the tip.
Hmm, frankly I think setting the timeout factor has a greater chance to
be maintenance free (no need to add further targets as they get
discovered) and I think a bit more flexible too. E.g. someone may (and
often will, if they care about their test run times) override the global
board timeout to say 5 from the default of 300 seconds in their board
description file for their super-fast test system and the timeout factor
will still do its work here. Whereas with the default timeout applying
here the lowest timeout setting that works here will be the global lower
limit, also for tests that are inherently faster than this one (i.e. don't
loop over thousands of iterations or in fact have no loop at all and just
execute in a fall-through manner) even on systems where lock contention is
not an issue.
If you think that extending the timeout for everyone is too big a hammer
here, then perhaps we could conditionalise it on
target_has_contentious_atomics or suchlike and list the right targets
there, but frankly I think it would be a bit of an overkill (and my
observation above about looped vs non-looped tests still applies).
Thoughts?
Maciej
next prev parent reply other threads:[~2014-09-04 17:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-03 14:08 Uros Bizjak
2014-09-04 17:39 ` Maciej W. Rozycki [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-09-16 21:05 David Edelsohn
2014-07-16 20:33 David Edelsohn
2014-08-01 3:28 ` David Edelsohn
2014-08-01 15:31 ` Joseph S. Myers
2014-08-06 20:21 ` Adhemerval Zanella
2014-08-19 16:54 ` Adhemerval Zanella
2014-09-02 22:23 ` Adhemerval Zanella
2014-09-03 14:01 ` Maciej W. Rozycki
2014-09-03 15:49 ` Joseph S. Myers
2014-09-04 18:40 ` Adhemerval Zanella
2014-09-15 14:38 ` Maciej W. Rozycki
2014-07-03 21:09 Adhemerval Zanella
2014-07-16 18:41 ` Adhemerval Zanella
2014-07-31 1:43 ` Joseph S. Myers
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=alpine.DEB.1.10.1409041824170.27075@tp.orcam.me.uk \
--to=macro@codesourcery.com \
--cc=azanella@linux.vnet.ibm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=ubizjak@gmail.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).