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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9BC21C433F5 for ; Tue, 1 Mar 2022 13:00:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E82878D0002; Tue, 1 Mar 2022 08:00:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E32CD8D0001; Tue, 1 Mar 2022 08:00:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D48B38D0002; Tue, 1 Mar 2022 08:00:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0052.hostedemail.com [216.40.44.52]) by kanga.kvack.org (Postfix) with ESMTP id C6C368D0001 for ; Tue, 1 Mar 2022 08:00:37 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 77F6E9D656 for ; Tue, 1 Mar 2022 13:00:37 +0000 (UTC) X-FDA: 79195826514.21.E401E4D Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) by imf20.hostedemail.com (Postfix) with ESMTP id 3DB301C001E for ; Tue, 1 Mar 2022 13:00:36 +0000 (UTC) Received: by mail-il1-f175.google.com with SMTP id k7so5472269ilo.8 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=Rz3PzFa6H7WAyemcIsGskwBDzTdueEVZskGz2BF0V4waEnoXeQnKjQ8SuEAK+wUiX3 s0NfE/lKnnLPAjQWt9OJutdGfyqHQTjovb00rjYSTwVV7JBEOpVmIAQJIeHdI3JaELuy hJoaONjDhGogJ8StLL8tFLL3McRAgfcMvoydLoy7s/W/VCAAkqFIqv8+Edr9F866afUP x2isAzu/vBI/Zw/UKkBcdv2R1y7Tc0tZuwCl1+NN3Thzbp/fZ9FFlpnrsqRr/dVdz3pi S0nabzx4opomiHzwP/1YQpHagoaielOsUP5GESccI3y+f2tdkymR0aDY+p+inA5Y6boR 99jQ== X-Gm-Message-State: AOAM531Cq/N2++M1ej5GczxyCmdaiMlVye2kNstiU8NCcSCypJ6Jaf7r qDmOTpJ5qiDG9tSQqnLlAFzkSWS82b/7sWSXt/Xfag== X-Google-Smtp-Source: ABdhPJygTkLKJoxpKoMnQComCB9wJUKiAgXMWJlY4Oqe0COwyi0CYb7/OKDFQvAmbtgocYjrHTjH3LgZXlKpwAjqw/Q= 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-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3DB301C001E X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=none ("invalid DKIM record") header.d=szeredi.hu header.s=google header.b=ZQjeLrdH; spf=pass (imf20.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.166.175 as permitted sender) smtp.mailfrom=miklos@szeredi.hu; dmarc=none X-Stat-Signature: zi7r1cd8m9kgzf5b4xm7uur8ritq9ad9 X-HE-Tag: 1646139636-330283 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 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