Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp3780414pxm; Tue, 1 Mar 2022 05:25:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJxU9Cuqn9A2Es5YWpcm4vUaG7yMFOB1hBSLzQeoz6lCVAjiHG7pjuwyNSdUiM3j0jpAGn89 X-Received: by 2002:a17:906:d8ab:b0:6d6:e98c:87a4 with SMTP id qc11-20020a170906d8ab00b006d6e98c87a4mr1540751ejb.668.1646141107151; Tue, 01 Mar 2022 05:25:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646141107; cv=none; d=google.com; s=arc-20160816; b=0ZLMxNoyNMWmaPg2O0ljkIfMmk5tV0IIC3IhWk9YLT3897o+9K1CNkNR2W/C25ZXOa SOdWVogezzcXDA3ubG9/snc2hh4iOq3Hufzm+lMnmBCefG503pMShZLU/EgntOVxrvQ3 YryKjCQavFZFdf6nResbMNaEK0QOsdpavC1KgV5uRIuKJrye2QZo3Ii1eDNpe/+/Qley Ec8YDhB4N4dOTdAMSyp5QMj8uZqYxJYo4C1XYNtR+cjizUsjc6hhIS20vDqAHp4vmJqL 2Tu6wIO6AGyL9FE7rhIDBCoHSmR7yFM6UI5ZrCh0OsHRK2AyALMsCadgKJ6COeoHq1XT vR+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=QG2k2eItwE4VAk3PGGex6QHZy3T0xaD3lTCoY/HpYco=; b=rn683xbK9tS5vMTCH0EKU6zEU/sq7yUPTl7hn28fyxSroYn9Bmwy45Nt0iKHrz4Yyw sCS5iyuRha6cBYabvZS86s2tt/E9EXpvkGvRJPbNNSpG3FZWvvSkVKof9QvjZu0udXrw 5pFC0oGp74tH773t3EDT6DPVQqgekaA95F8ZNTgqVm3JjtQB5rjvkTskTNNmfZUqSTPx klzh6bNugJa68XtLb2+/KwD6RAp4Vw3T5hESK5N+DOHtmPeDcz+zTS8MVYOSP1p3Sq8x lCGfZUDfqaxgPh8M+RkDDULxxvua+sGTeEjYB46aH7G3WlzZlo+NjNdjDbCmxbAnCJlM jxFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=ZQjeLrdH; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ey10-20020a1709070b8a00b006d0a70ea866si6925480ejc.946.2022.03.01.05.24.30; Tue, 01 Mar 2022 05:25:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-nfs-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=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=ZQjeLrdH; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234901AbiCANBT (ORCPT + 99 others); Tue, 1 Mar 2022 08:01:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48220 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234883AbiCANBR (ORCPT ); Tue, 1 Mar 2022 08:01:17 -0500 Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B847D9A4CE for ; Tue, 1 Mar 2022 05:00:35 -0800 (PST) Received: by mail-il1-x134.google.com with SMTP id y5so12428535ill.13 for ; Tue, 01 Mar 2022 05:00:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QG2k2eItwE4VAk3PGGex6QHZy3T0xaD3lTCoY/HpYco=; b=ZQjeLrdHbWEck4K6RpeBY4QI1uE5CcoVwO5sZTKvbH0jCtE/epL+AV1J2T6nTvQB7B /yPS0KVOUZAhUGfHU54H1jmlgYJUgdfLLmM3xmB3rY9RzzFoWNFI2Zci83Jzu2Okp0E4 AJRAtv/WKjpa/XnIsui/qXUZ2c4GyPza8OAZk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QG2k2eItwE4VAk3PGGex6QHZy3T0xaD3lTCoY/HpYco=; b=bjOiyRVEW/hrs+nJaY87JD4uT5dhc1rYUCTaV4XAvX0WRH9kVX7CTDrvN1406C+79P GMa7bEpWyWpQI3H//ikd3Wh0AplyxjkKGDtM8HDzJQN2/FpiRlda5LyYq0pYfJizpXfB o+wzQI0p5gB18lu8ST63OI+3OqUIPZk2BDqJjrG/JYTSMky3wak+TjYZiemGyuksC32a eLMxt8XsEeq7M5ep/7VMEeK/Ad38sXQP2I3EZvsCXctp2EXCg+SNDtTqkkEoW1So4smi hQvG13coNLPm95IMaDn9viEEJTzkXT/lZvRwPosS3UeRlB8AcXZNqqK/kcFZgNx9nSnW onDQ== X-Gm-Message-State: AOAM530deG45ignxf1haZAPdqHBe0F/+QYppydVq1rIz91RvrBPextKp UjoKPBmDkdHbIpu3++PzIEo4NM1NoHeFPoBlA2jlRQ== X-Received: by 2002:a92:cf12:0:b0:2be:3a27:67c7 with SMTP id c18-20020a92cf12000000b002be3a2767c7mr23363367ilo.187.1646139635155; Tue, 01 Mar 2022 05:00:35 -0800 (PST) MIME-Version: 1.0 References: <164549971112.9187.16871723439770288255.stgit@noble.brown> <164549983736.9187.16755913785880819183.stgit@noble.brown> In-Reply-To: <164549983736.9187.16755913785880819183.stgit@noble.brown> From: Miklos Szeredi Date: Tue, 1 Mar 2022 14:00:24 +0100 Message-ID: Subject: Re: [PATCH 03/11] MM: improve cleanup when ->readpages doesn't process all pages. To: NeilBrown 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 Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no 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-nfs@vger.kernel.org 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 = readahead_page(rac))) { > + rac->ra->size -= 1; > + if (rac->ra->async_size > 0) { > + rac->ra->async_size -= 1; > + delete_from_page_cache(page); > + } Does the above imply that filesystem should submit at least ra->size pages, regardless of congestion? Thanks, Miklos