[LTP] [PATCH v2] read_all: retry to queue work for any worker

[Li Wang]

On Sun, Oct 13, 2019 at 3:54 PM Jan Stancek <jstancek@redhat.com> wrote:

>
>
> ----- Original Message -----
> > On Sat, Oct 12, 2019 at 2:49 PM Jan Stancek <jstancek@redhat.com> wrote:
> >
> > > ...
> > > > > > Base on your patch, I'm thinking to achieve a new macro
> > > TST_INFILOOP_FUNC
> > > > > > which can repeat the @FUNC infinitely. Do you feel it satisfies
> your
> > > > > > requirements to some degree or meaningful to LTP?
> > > > >
> > > > > I'm OK with concept. I'd like more some variation of *RETRY* for
> name.
> > > > > Comments below.
> > > > >
> > > >
> > > > Thanks, what about naming: TST_INFI_RETRY_FUNC?
> > >
> > > Or just keep TST_RETRY_FUNC and add parameter to it?
> > >
> >
> > Sounds better, we could add parameter @INFI to control the retry as a
> knob.
> >
> > /* @INFI - 1: retry infinitely, 0: retry in limit times */
> >
> > #define TST_RETRY_FUNC(FUNC, ERET, INFI) \
> >         TST_RETRY_FN_EXP_BACKOFF(FUNC, ERET, 1, INFI)
>
> Other option is we use directly TST_RETRY_FN_EXP_BACKOFF.
>

I'm ok for either. I will have a try when I get a chance since mkswap01.sh
sometimes timed out in the one-second retrying.


>
> >
> >
> > > >
> > > > And do you mind use it to replace your function work_push_retry()? I
> know
> > > > it may be not smarter than work_push_retry() but it looks tiny for
> code.
> > >
> > > It may need some wrapper, because work_push_retry() may be passing
> > > different
> > > argument to function on each retry, which was one of reasons for the
> patch.
> > >
> >
> > I was not meaning to hack the work_push_retry() function, I mean to
> change
> > your patch as below after we improve the TST_RETRY_FUNC.
>
> Why not? Wouldn't we get better performance if we don't wait on specific
> worker
> to complete?
>
Well, right! You can merge this patch as it is.

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20191014/37921d27/attachment.htm>