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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 916A5C433E0 for ; Wed, 24 Feb 2021 13:41:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1CBC464EBA for ; Wed, 24 Feb 2021 13:41:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1CBC464EBA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4B0FE6B006E; Wed, 24 Feb 2021 08:41:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 462896B0070; Wed, 24 Feb 2021 08:41:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 379438D0001; Wed, 24 Feb 2021 08:41:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 201186B006E for ; Wed, 24 Feb 2021 08:41:35 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id DC0BFA748 for ; Wed, 24 Feb 2021 13:41:34 +0000 (UTC) X-FDA: 77853273708.02.9178B01 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf06.hostedemail.com (Postfix) with ESMTP id 3DD96C0007C8 for ; Wed, 24 Feb 2021 13:41:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=xqha6KaFHgtvIKBaYdn52JwvfxXRN9RcHQ72fzYOeuc=; b=sXng7xDNXehmcnr+hW/CSKnK/Q rvJT1OrIAsqWa9NN8xPC9n3JB67aLuQc2z/fV0E1k3Ec/VnIEdSzmtm1OAdBOJq1uPxrXe9j35Var hgFb42qG7+e4qFPooFPcxYWXx5OwRaM5RixwDaIlmOM4BaZFTtYvMZpL57/LvY9Pq/ufZ7zgSNxH6 YirC1u+3y9MMSC14hmmHiSkNiAI9PSRdM5kq0tTHEU8xFm74X0qWSGMpNyG4yP+YTs+LTIn9rvQw2 n1NkwimRKMjDpd5nbMqzJHT5MoOlSfnFjidjke0IfLaJQJPsUAq8vIocd5kZE8FA2HsJJsdogN0B2 wHLmVtyA==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lEuPj-009SVQ-M3; Wed, 24 Feb 2021 13:41:16 +0000 Date: Wed, 24 Feb 2021 13:41:15 +0000 From: Matthew Wilcox To: Jan Kara Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christoph Hellwig , Kent Overstreet Subject: Re: [RFC] Better page cache error handling Message-ID: <20210224134115.GP2858050@casper.infradead.org> References: <20210205161142.GI308988@casper.infradead.org> <20210224123848.GA27695@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210224123848.GA27695@quack2.suse.cz> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 3DD96C0007C8 X-Stat-Signature: 7dqy37quwuwah7o589ha5atfjyghi3ps Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf06; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614174093-271538 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 Wed, Feb 24, 2021 at 01:38:48PM +0100, Jan Kara wrote: > > We allocate a page and try to read it. 29 threads pile up waiting > > for the page lock in filemap_update_page(). The error returned by the > > original I/O is shared between all 29 waiters as well as being returned > > to the requesting thread. The next request for index.html will send > > another I/O, and more waiters will pile up trying to get the page lock, > > but at no time will more than 30 threads be waiting for the I/O to fail. > > Interesting idea. It certainly improves current behavior. I just wonder > whether this isn't a partial solution to a problem and a full solution of > it would have to go in a different direction? I mean it just seems > wrong that each reader (let's assume they just won't overlap) has to retry > the failed IO and wait for the HW to figure out it's not going to work. > Shouldn't we cache the error state with the page? And I understand that we > then also have to deal with the problem how to invalidate the error state > when the block might eventually become readable (for stuff like temporary > IO failures). That would need some signalling from the driver to the page > cache, maybe in a form of some error recovery sequence counter or something > like that. For stuff like iSCSI, multipath, or NBD it could be doable I > believe... That felt like a larger change than I wanted to make. I already have a few big projects on my plate! Also, it's not clear to me that the host can necessarily figure out when a device has fixed an error -- certainly for the three cases you list it can be done. I think we'd want a timer to indicate that it's worth retrying instead of returning the error. Anyway, that seems like a lot of data to cram into a struct page. So I think my proposal is still worth pursuing while waiting for someone to come up with a perfect solution.