Re: [PATCH 2/2] tests: introduce --stress-jobs=<N>
- Date: Sun, 3 Mar 2019 15:47:01 +0100 (STD)
- From: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
- Subject: Re: [PATCH 2/2] tests: introduce --stress-jobs=<N>
On Sun, 3 Mar 2019, SZEDER Gábor wrote:
> On Sat, Mar 02, 2019 at 01:19:44PM -0800, Johannes Schindelin via GitGitGadget wrote:
> > The --stress option currently accepts an argument, but it is confusing
> > to at least this user that the argument does not define the maximal
> > number of stress iterations, but instead the number of jobs to run in
> > parallel per stress iteration.
> Well, these options' description in 't/README' is quite clear on what
> they do. If the lack of updates to 't/README' in these patches is any
> indication, then you haven't read that :) but doing so might very well
> have avoided your confusion in the first place.
Yep, hadn't read it, assumed that it was obvious that `--stress=<N>`
meant: try for at most <N> times to replicate the issue.
Which to me is a good indicator that the UI could be improved...
> According to my Bash history, I used '--stress=<even-more-cpu-cores>'
> about 20x more often than '--stress-limit=<N>'. That's not surprising
> at all, since the main point is to try to trigger rare, hard to
> reproduce failures, no matter how many repetitions it takes. And even
> if there is an upper bound, it is usually not the number of repetitions
> I know in advance, but rather the time I'm willing to sacrifice on it,
> e.g. how long I'm on lunch break or doing groceries, or when I need my
> CPUs for more important things, or simply when I give up, and hit
I don't doubt that *you* need `--stress-jobs=<N>` more often than
`--stress-limit=<N>`, but I really think that common users will need the
latter a lot more often (if they need the former at all).
> And with --stress-jobs=<N> I will have to type more :)