Re: [PATCH] block: fix -EAGAIN IOPOLL task/vm accounting

[Jens Axboe <axboe@kernel.dk>]

On 8/30/20 9:28 AM, Christoph Hellwig wrote:
> On Sun, Aug 30, 2020 at 09:09:02AM -0600, Jens Axboe wrote:
>> On 8/30/20 12:26 AM, Christoph Hellwig wrote:
>>> On Sat, Aug 29, 2020 at 10:51:11AM -0600, Jens Axboe wrote:
>>>> We currently increment the task/vm counts when we first attempt to queue a
>>>> bio. But this isn't necessarily correct - if the request allocation fails
>>>> with -EAGAIN, for example, and the caller retries, then we'll over-account
>>>> by as many retries as are done.
>>>>
>>>> This can happen for polled IO, where we cannot wait for requests. Hence
>>>> retries can get aggressive, if we're running out of requests. If this
>>>> happens, then watching the IO rates in vmstat are incorrect as they count
>>>> every issue attempt as successful and hence the stats are inflated by
>>>> quite a lot potentially.
>>>>
>>>> Add a bio flag to know if we've done accounting or not. This prevents
>>>> the same bio from being accounted potentially many times, when retried.
>>>
>>> Can't the resubmitter just use submit_bio_noacct?  What is the call
>>> stack here?
>>
>> The resubmitter is way higher than that. You could potentially have that
>> done in the block layer, but not higher up.
>>
>> The use case is async submissions, going through ->read_iter() again.
>> Or ->write_iter().
> 
> But how does a bio flag help there?  If we go through the file ops
> again the next submission will be a new bio structure.

Yeah the patch is garbage, can't work. The previous suggestion is here:

https://lore.kernel.org/linux-block/395b4c19-cc80-eebb-f6ab-04687110c84a@kernel.dk/T/

which isn't super pretty either, but at least it works. Not sure there's
a better solution, outside of marking the iocb as retry and then
carrying that flag forward for the bio as well. And that seems a bit
much for this case.

-- 
Jens Axboe