Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp1584505pxm; Thu, 3 Mar 2022 22:33:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJwn/B2HQcLKoLaITKQ8B3jElWxCOaSd+cs5rpiHqzTpWZryOSFaM8h0+/Y8kP6AOjaeiu4V X-Received: by 2002:a05:6402:4304:b0:415:e895:ab9f with SMTP id m4-20020a056402430400b00415e895ab9fmr4985538edc.79.1646375608236; Thu, 03 Mar 2022 22:33:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646375608; cv=none; d=google.com; s=arc-20160816; b=NbFYS+Fh1XJXEKOQgNkyCQiHcD020mHCqZbmcjQTlYyV7lAuaWxzbJP0Dv1yuH0oA4 yKI0HqZXBtqFlEPbANwE99tpbektgwP4CTHNJcykUZkIiNTP8MDSUThk0twoxDXO/JFy l+16fyC+x3bOX+iv7Wach1QJw4V7MlnRjEaq5ltKGtckAYxfhnJCy9KTc5TS+2KvyA/n 8HxDU2aRGgZzrHtKhzJ61+TTact4HV1hAsk4sHoKVauABJ8kItHLWjKFQUBTMD/veZYA 8CykRTi5v+GBsAD/4FQFtaUykaqMlnUz+1sSeFHSTD+RAq10XV8KoDDoz2JGhTCPShL1 cCVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:references:in-reply-to:subject :cc:to:from:mime-version:content-transfer-encoding:dkim-signature :dkim-signature; bh=E85sAoXCaTA9rJMXOcKl8Th+xCpRXA0b8EAqZxwZ8A0=; b=oCw3EKYj32Oe93xAxE5XyxLooGnZMiCE47mLV/KdkArrRQOs/vV7UxGHe/aD3I57Ih 2NRGOLVF15SUnBwQjbsH4wrAe8aon2sPRizn3AbrskqOi9fxprmtcsU6J2Gv1nWDqTfv wx4eYZYDEh/R2OZ31ZYi9ChNkRhNHiLH19HjFj+QdygN51PVOG2ku4Pw63/ducWpqBr+ KMEG+XudFq3/2erhFwBfEnxtcfESrJPeKjpi661qF1DYBAyfCUtlw3D8xa9fShvwG5Wn 1gCtgYpnAcvyAlOOERUIw0cG1oBf3SZazJUa1cwx873Ux9jEXqSTJMGnwriuz0gocppz BNtw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=OHMBIepy; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=gt1xKH0i; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g1-20020a1709065d0100b006cf37fdb0cfsi3996619ejt.936.2022.03.03.22.33.05; Thu, 03 Mar 2022 22:33:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=OHMBIepy; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=gt1xKH0i; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237685AbiCDCYR (ORCPT + 99 others); Thu, 3 Mar 2022 21:24:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232705AbiCDCYN (ORCPT ); Thu, 3 Mar 2022 21:24:13 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3668565820; Thu, 3 Mar 2022 18:23:26 -0800 (PST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 977441F382; Fri, 4 Mar 2022 02:23:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1646360604; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=E85sAoXCaTA9rJMXOcKl8Th+xCpRXA0b8EAqZxwZ8A0=; b=OHMBIepyGZT5p2vUzh9m6EF2ADllsCUvjfoI6pTTrXo7Yz0B7BDN+ge9IdtF+2ZYydZGCQ 8WoB5pAABgNBYEPVBbEaEnFFjU93OJpcylm9mmoQGVwXSBRAGZ9mDxUgC5aU5qlMH9Ckr8 8JdQlmMLB5FGrAN6piwNc9Z7wosEfx8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1646360604; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=E85sAoXCaTA9rJMXOcKl8Th+xCpRXA0b8EAqZxwZ8A0=; b=gt1xKH0idJAvV5toxul/AJtWemJaGkXOxCg34os0vjwsTU/KiA45a4f222DhjpE4Y5De+j w3347cZDZ/LwPhDw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 8CAE41340A; Fri, 4 Mar 2022 02:23:17 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Wj8UEhV4IWIXewAAMHmgww (envelope-from ); Fri, 04 Mar 2022 02:23:17 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "NeilBrown" To: "Miklos Szeredi" Cc: "Andrew Morton" , "Jan Kara" , "Wu Fengguang" , "Jaegeuk Kim" , "Chao Yu" , "Jeff Layton" , "Ilya Dryomov" , "Trond Myklebust" , "Anna Schumaker" , "Ryusuke Konishi" , "Darrick J. Wong" , "Philipp Reisner" , "Lars Ellenberg" , "Paolo Valente" , "Jens Axboe" , linux-doc@vger.kernel.org, "linux-mm" , linux-nilfs@vger.kernel.org, "Linux NFS list" , linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, "Ext4" , ceph-devel@vger.kernel.org, drbd-dev@lists.linbit.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 03/11] MM: improve cleanup when ->readpages doesn't process all pages. In-reply-to: References: <164549971112.9187.16871723439770288255.stgit@noble.brown>, <164549983736.9187.16755913785880819183.stgit@noble.brown>, Date: Fri, 04 Mar 2022 13:23:14 +1100 Message-id: <164636059432.13165.6442580674358743838@noble.neil.brown.name> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 02 Mar 2022, Miklos Szeredi wrote: > On Tue, 22 Feb 2022 at 04:18, NeilBrown wrote: > > > > If ->readpages doesn't process all the pages, then it is best to act as > > though they weren't requested so that a subsequent readahead can try > > again. > > So: > > - remove any 'ahead' pages from the page cache so they can be loaded > > with ->readahead() rather then multiple ->read()s > > - update the file_ra_state to reflect the reads that were actually > > submitted. > > > > This allows ->readpages() to abort early due e.g. to congestion, which > > will then allow us to remove the inode_read_congested() test from > > page_Cache_async_ra(). > > > > Signed-off-by: NeilBrown > > --- > > mm/readahead.c | 19 +++++++++++++++++-- > > 1 file changed, 17 insertions(+), 2 deletions(-) > > > > diff --git a/mm/readahead.c b/mm/readahead.c > > index 73b2bc5302e0..8a97bd408cf6 100644 > > --- a/mm/readahead.c > > +++ b/mm/readahead.c > > @@ -104,7 +104,13 @@ > > * for necessary resources (e.g. memory or indexing information) to > > * become available. Pages in the final ``async_size`` may be > > * considered less urgent and failure to read them is more acceptable. > > - * They will eventually be read individually using ->readpage(). > > + * In this case it is best to use delete_from_page_cache() to remove the > > + * pages from the page cache as is automatically done for pages that > > + * were not fetched with readahead_page(). This will allow a > > + * subsequent synchronous read ahead request to try them again. If they > > + * are left in the page cache, then they will be read individually using > > + * ->readpage(). > > + * > > */ > > > > #include > > @@ -226,8 +232,17 @@ static void read_pages(struct readahead_control *rac= , struct list_head *pages, > > > > if (aops->readahead) { > > aops->readahead(rac); > > - /* Clean up the remaining pages */ > > + /* > > + * Clean up the remaining pages. The sizes in ->ra > > + * maybe be used to size next read-ahead, so make sure > > + * they accurately reflect what happened. > > + */ > > while ((page =3D readahead_page(rac))) { > > + rac->ra->size -=3D 1; > > + if (rac->ra->async_size > 0) { > > + rac->ra->async_size -=3D 1; > > + delete_from_page_cache(page); > > + } >=20 > Does the above imply that filesystem should submit at least ra->size > pages, regardless of congestion? ra->size - ra_async_size=20 pages should be submitted reguardless of congestion. NeilBrown