Bug 205298
| Summary: | Re-tune JSC tests timeout value now that we can timeout based on CPU time. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Mark Lam <mark.lam> |
| Component: | JavaScriptCore | Assignee: | Mark Lam <mark.lam> |
| Status: | ASSIGNED | ||
| Severity: | Normal | CC: | ap |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 205279 | ||
| Bug Blocks: | |||
Mark Lam
Also
(1) investigate removing s_timeoutMultiplier. It was only needed to pad the timeout value for some tests.
(2) investigate unskipping tests that were previously flaky due to timeouts.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Mark Lam
After playing with the timeout values for the JSC tests a bit, I came to the following conclusion:
(In reply to Mark Lam from comment #0)
> Also
> (1) investigate removing s_timeoutMultiplier. It was only needed to pad the
> timeout value for some tests.
We should keep this option because it allows us to grant more time to certain tests that are intrinsically long running, without having to lengthen the timeout value for all tests.
I also think we should not change the current timeout values. Our tests are already tuned for these timeout values. Shortening the timeout values will only cause more churn to add --timeoutMultipliers to the new tests that will start timing out. I don't think there's much value in that given the current timeout value isn't prohibitively long.
> (2) investigate unskipping tests that were previously flaky due to timeouts.
Still need to investigate this.