From: Jens Axboe <axboe@kernel.dk>
To: Christoph Hellwig <hch@infradead.org>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH] block: fix -EAGAIN IOPOLL task/vm accounting
Date: Mon, 31 Aug 2020 08:02:43 -0600 [thread overview]
Message-ID: <ebdb0929-782c-fb66-e3e9-86c077e3b710@kernel.dk> (raw)
In-Reply-To: <20200830152800.GA16467@infradead.org>
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
next prev parent reply other threads:[~2020-08-31 14:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-29 16:51 [PATCH] block: fix -EAGAIN IOPOLL task/vm accounting Jens Axboe
2020-08-30 6:26 ` Christoph Hellwig
2020-08-30 15:09 ` Jens Axboe
2020-08-30 15:28 ` Christoph Hellwig
2020-08-31 3:12 ` Ming Lei
2020-08-31 14:02 ` Jens Axboe [this message]
2020-08-31 14:12 ` Christoph Hellwig
2020-08-31 14:18 ` Jens Axboe
2020-09-01 5:42 ` Christoph Hellwig
2020-09-01 14:01 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ebdb0929-782c-fb66-e3e9-86c077e3b710@kernel.dk \
--to=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).