Web lists-archives.com

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

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 :)

Sorry ;-)