On Fri, Jul 17, 2015 at 6:23 PM, Andrey Kuzmin <andrey.v.kuzmin@xxxxxxxxx> wrote: > > On Jul 17, 2015 6:11 PM, "Jens Axboe" <axboe@xxxxxxxxx> wrote: >> >> On 07/17/2015 09:02 AM, Andrey Kuzmin wrote: >>> >>> On Fri, Jul 17, 2015 at 5:58 PM, Jens Axboe <axboe@xxxxxxxxx> wrote: >>>> >>>> On 07/17/2015 08:53 AM, Andrey Kuzmin wrote: >>>>> >>>>> >>>>> >>>>> On Jul 17, 2015 5:36 PM, "Jens Axboe" <axboe@xxxxxxxxx >>>>> <mailto:axboe@xxxxxxxxx>> wrote: >>>>> > >>>>> > On 07/17/2015 08:30 AM, Andrey Kuzmin wrote: >>>>> >> >>>>> >> Probably worth adding to do_verify() as well. >>>>> > >>>>> > >>>>> > Might be better to ensure that they are reaped when we break out of >>>>> the loop instead? >>>>> > >>>>> >>>>> That's exactly what happens with the patch, doesn't it? >>>> >>>> >>>> >>>> It might be... It's not very clear why a !td->cur_depth should force us >>>> to >>>> stay in the loop? >>> >>> >>> Because to me breaking out of the loop on time- or size-based limit >>> exceeded condition with a non-zero td->cur_depth means loosing >>> completions. >> >> >> That's what I thought. Hence my suggestion would be that we reap any >> potentially inflight IO _outside_ of the loop, that would be a lot cleaner. Turned out the extant completion reaping code that follows the break out from the main loop is perfectly sufficient, provided the engine properly appreciates the minimum number of completions required (which mine didn't). Withdrawing the original patch request. Regards, Andrey >> > Agreed, will look into the reaping code. > > Regards, > A. >> -- >> Jens Axboe >> -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
