From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85321C433E0 for ; Fri, 19 Jun 2020 14:36:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 49B18208B8 for ; Fri, 19 Jun 2020 14:36:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=kernel-dk.20150623.gappssmtp.com header.i=@kernel-dk.20150623.gappssmtp.com header.b="uqgJVkp2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 49B18208B8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C265C8D00AC; Fri, 19 Jun 2020 10:36:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BD7128D00A6; Fri, 19 Jun 2020 10:36:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC5498D00AC; Fri, 19 Jun 2020 10:36:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) by kanga.kvack.org (Postfix) with ESMTP id 945B68D00A6 for ; Fri, 19 Jun 2020 10:36:45 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 10F22250C8 for ; Fri, 19 Jun 2020 14:36:45 +0000 (UTC) X-FDA: 76946212770.23.war10_510cf3326e19 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id BD2F53760C for ; Fri, 19 Jun 2020 14:36:44 +0000 (UTC) X-HE-Tag: war10_510cf3326e19 X-Filterd-Recvd-Size: 7482 Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Fri, 19 Jun 2020 14:36:44 +0000 (UTC) Received: by mail-pg1-f193.google.com with SMTP id d4so4574945pgk.4 for ; Fri, 19 Jun 2020 07:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=pZm6yfNYNBuxBStKZC0kZanPMnKOlf2CgfGPgI4tuHQ=; b=uqgJVkp2ta13UJdmiW7Lw1bFtHRXApq/tVCDyt3pdUyhLeTsrd5cL3WhGO3XyEGEUj lnDHihZwWdimLe6RISBNN32+ELxaLgJ8/y4dcXDHN/GHrdU63EgDC4BsgFD/CQ6bxmSX BjsUEvg1+/6CaqfL4ZohtQouempwFJyB34irxdn3pQwDv4FXJtpk8F1knNvZbWe6dk/G tiUPF0iInhm/PXgGCIKHtskVRZq78Pb81cuOlKAUYpeAp39mlQEZWasHKf/6KecRgIqq 2Qyeok7cXRpAZFm11moXK535vCVJ5QuNGI/Ob/P1YI1oIVBOQIh+UXokJpmC3VimY6mL 0IpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pZm6yfNYNBuxBStKZC0kZanPMnKOlf2CgfGPgI4tuHQ=; b=CnzwoQIhqqrOBAbdI5hySFBw/9SOynjhjdnWbB/EK7P5NG+7k4j3NECtK+YPx8/sTs BiNDPHvXL3YrC3nN+86ZN2w4Yr+NIOJaTpw1mWEChkJ/wW5G+hIRYAHtIg5hvZwqi2BH in2K4NbjUxOozoCgaNVpUOuT3pqfW9+CJvdV59tSP9EBakZaFP1J94ZVUssLRN+F8w81 gSr1o6ufzkfwDrqvzMbYgsUY9pul58ozZIiI1xD/ZSthoPuXmjGuayz77DQziv6llEA+ l4ofVwKN2sUaY8aUzJTzTlv+DZ8f9gs3IGp4iCV8W8Zk8swAHDtetlybAMeTtnGYrvbz OBmA== X-Gm-Message-State: AOAM5311rBd9W5sKafy4/tuuTJoM2iC+R6Umbhw63cEfULoFM+gQSkTg uWRb+WamGwbaXjIaGdU3FqUimw== X-Google-Smtp-Source: ABdhPJwLZap2gCbNRLjuZq9p47CcZnx/KyR0tvZKTiGdcuRCXJAnOlkelvd5T5h1TxDPz4q9D8EYAA== X-Received: by 2002:a62:640b:: with SMTP id y11mr8309607pfb.195.1592577403047; Fri, 19 Jun 2020 07:36:43 -0700 (PDT) Received: from [192.168.1.188] ([66.219.217.173]) by smtp.gmail.com with ESMTPSA id b191sm5484675pga.13.2020.06.19.07.36.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 07:36:42 -0700 (PDT) Subject: Re: [PATCH 04/15] io_uring: re-issue block requests that failed because of resources To: Pavel Begunkov , io-uring@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org References: <20200618144355.17324-1-axboe@kernel.dk> <20200618144355.17324-5-axboe@kernel.dk> <105a78f0-407f-09e3-5951-7f76756762b2@gmail.com> From: Jens Axboe Message-ID: Date: Fri, 19 Jun 2020 08:36:41 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <105a78f0-407f-09e3-5951-7f76756762b2@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: BD2F53760C X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 6/19/20 8:30 AM, Pavel Begunkov wrote: > On 19/06/2020 17:22, Jens Axboe wrote: >> On 6/19/20 8:12 AM, Pavel Begunkov wrote: >>> On 18/06/2020 17:43, Jens Axboe wrote: >>>> Mark the plug with nowait == true, which will cause requests to avoid >>>> blocking on request allocation. If they do, we catch them and reissue >>>> them from a task_work based handler. >>>> >>>> Normally we can catch -EAGAIN directly, but the hard case is for split >>>> requests. As an example, the application issues a 512KB request. The >>>> block core will split this into 128KB if that's the max size for the >>>> device. The first request issues just fine, but we run into -EAGAIN for >>>> some latter splits for the same request. As the bio is split, we don't >>>> get to see the -EAGAIN until one of the actual reads complete, and hence >>>> we cannot handle it inline as part of submission. >>>> >>>> This does potentially cause re-reads of parts of the range, as the whole >>>> request is reissued. There's currently no better way to handle this. >>>> >>>> Signed-off-by: Jens Axboe >>>> --- >>>> fs/io_uring.c | 148 ++++++++++++++++++++++++++++++++++++++++++-------- >>>> 1 file changed, 124 insertions(+), 24 deletions(-) >>>> >>>> diff --git a/fs/io_uring.c b/fs/io_uring.c >>>> index 2e257c5a1866..40413fb9d07b 100644 >>>> --- a/fs/io_uring.c >>>> +++ b/fs/io_uring.c >>>> @@ -900,6 +900,13 @@ static int io_file_get(struct io_submit_state *state, struct io_kiocb *req, >>>> static void __io_queue_sqe(struct io_kiocb *req, >>>> const struct io_uring_sqe *sqe); >>>> >>> ...> + >>>> +static void io_rw_resubmit(struct callback_head *cb) >>>> +{ >>>> + struct io_kiocb *req = container_of(cb, struct io_kiocb, task_work); >>>> + struct io_ring_ctx *ctx = req->ctx; >>>> + int err; >>>> + >>>> + __set_current_state(TASK_RUNNING); >>>> + >>>> + err = io_sq_thread_acquire_mm(ctx, req); >>>> + >>>> + if (io_resubmit_prep(req, err)) { >>>> + refcount_inc(&req->refs); >>>> + io_queue_async_work(req); >>>> + } >>> >>> Hmm, I have similar stuff but for iopoll. On top removing grab_env* for >>> linked reqs and some extra. I think I'll rebase on top of this. >> >> Yes, there's certainly overlap there. I consider this series basically >> wrapped up, so feel free to just base on top of it. >> >>>> +static bool io_rw_reissue(struct io_kiocb *req, long res) >>>> +{ >>>> +#ifdef CONFIG_BLOCK >>>> + struct task_struct *tsk; >>>> + int ret; >>>> + >>>> + if ((res != -EAGAIN && res != -EOPNOTSUPP) || io_wq_current_is_worker()) >>>> + return false; >>>> + >>>> + tsk = req->task; >>>> + init_task_work(&req->task_work, io_rw_resubmit); >>>> + ret = task_work_add(tsk, &req->task_work, true); >>> >>> I don't like that the request becomes un-discoverable for cancellation >>> awhile sitting in the task_work list. Poll stuff at least have hash_node >>> for that. >> >> Async buffered IO was never cancelable, so it doesn't really matter. >> It's tied to the task, so we know it'll get executed - either run, or >> canceled if the task is going away. This is really not that different >> from having the work discoverable through io-wq queueing before, since >> the latter could never be canceled anyway as it sits there >> uninterruptibly waiting for IO completion. > > Makes sense. I was thinking about using this task-requeue for all kinds > of requests. Though, instead of speculating it'd be better for me to embody > ideas into patches and see. And that's fine, for requests where it matters, on-the-side discoverability can still be a thing. If we're in the task itself where it is queued, that provides us safey from the work going way from under us. Then we just have to mark it appropriately, if it needs to get canceled instead of run to completion. Some care needed, of course, but there's nothing that would prevent this from working. Ideally we'd be able to peal off a task_work entry, but that's kind of difficult with the singly linked non-locked list. -- Jens Axboe