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.6 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 598F1C07E99 for ; Mon, 12 Jul 2021 14:38:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CF6DE61106 for ; Mon, 12 Jul 2021 14:38:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CF6DE61106 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 D57CE6B00AB; Mon, 12 Jul 2021 10:38:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CBDC46B00AD; Mon, 12 Jul 2021 10:38:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B85B38D000B; Mon, 12 Jul 2021 10:38:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0057.hostedemail.com [216.40.44.57]) by kanga.kvack.org (Postfix) with ESMTP id 8DE826B00AB for ; Mon, 12 Jul 2021 10:38:46 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 9ECA016485 for ; Mon, 12 Jul 2021 14:38:45 +0000 (UTC) X-FDA: 78354192210.31.6545EC2 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf14.hostedemail.com (Postfix) with ESMTP id 8B7DB60019A6; Mon, 12 Jul 2021 14:38:44 +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=Zi6WvyUoRpg2h8P9u2NqZlcgTX1hCKKGUHrSN74lVfY=; b=ctN8+h0TXRH6w4a8PvJ0G554pM P0I+WXOy/gAJ0Kro6EZwZjr3GHXEuZyNTMzV6rpjI7s6BCCTLPyj2iMhxjIiargWCLPVsz5MnWOfj dqJxG2XFhuWWnug9x2ZC2/C/jidp5WIoC9M19NIzVZojsmLcQmbJocT/zopAdCI2D9OC5w4iAxnR9 Iq3sKs+iEtMqRLUKBXkaXigQ+qfAzasspLGs1O6ObsDNvhak+sqA6R/VerdWgj7We/TLHIgxkhE5a JXg5hXT2yPL2fIvQA46PzkbGC7af8kym/ZASLyNAkEASfykDnj1u6/vNjDt2h0AaRvgwqzFpyNj/o qZ2FfYBQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1m2x43-0007lL-H9; Mon, 12 Jul 2021 14:37:52 +0000 Date: Mon, 12 Jul 2021 15:37:43 +0100 From: Matthew Wilcox To: Christoph Hellwig Cc: Jens Axboe , io-uring@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-aio@kvack.org Subject: Re: [PATCH 1/2] mm/readahead: Add gfp_flags to ractl Message-ID: References: <20210711150927.3898403-1-willy@infradead.org> <20210711150927.3898403-2-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ctN8+h0T; spf=none (imf14.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 8B7DB60019A6 X-Stat-Signature: e5ii3zpsj941xowts33et6mztzbqiu1k X-HE-Tag: 1626100724-535170 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 Mon, Jul 12, 2021 at 12:34:23PM +0100, Christoph Hellwig wrote: > On Sun, Jul 11, 2021 at 04:09:26PM +0100, Matthew Wilcox (Oracle) wrote: > > It is currently possible for an I/O request that specifies IOCB_NOWAIT > > to sleep waiting for I/O to complete in order to allocate pages for > > readahead. In order to fix that, we need the caller to be able to > > specify the GFP flags to use for memory allocation in the rest of the > > readahead path. > > The file systems also need to respect it for their bio or private > data allocation. And be able to cope with failure, which they currently > don't have to for sleeping bio allocations. Yes, they should. This patch doesn't make that problem worse than it is today, and gets the desired GFP flags down to the file systems, which is needed for the full fix.