Re: [PATCH 2/2] tests: introduce --stress-jobs=<N>

> 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.

> 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
> ctrl-C.