Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp3798382pxm; Tue, 1 Mar 2022 05:44:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJx572F6XJNekDM1ALOK4AzATSZ0gifdwl891EZojqf7fGoU7BW5xqTHGkybXPYZlbsi4Pnv X-Received: by 2002:aa7:d949:0:b0:40f:2aa1:1bd1 with SMTP id l9-20020aa7d949000000b0040f2aa11bd1mr24690733eds.284.1646142271385; Tue, 01 Mar 2022 05:44:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646142271; cv=none; d=google.com; s=arc-20160816; b=zwoxRFiLUjHD+VCvYhFJjgoB+5eKzVV2gNLeybXq0fmmfBmp4J3vs+z4Hw2o0qyr9b 7zx1lF8TfrFPTrHEEDzVgXHTTGw8A8sAIjLK45uaYzwzNr5kJOoAz1xsRvn2iwmpMwVH rI3dleVJvwD+zjCuUbVYY8w5vXS1hZBHEiYYXYvgLKyerRFN3gBejcsF7Zxz9q4XhvLh XOSYGP2uoZWZR9vaH72DzF56kurUQIW/GEpRsNeFzNH+D1gFRFO7ucat1lAKLQGTlnxl O2xju0WGm3WoS02ExxEX4/3EzGylVX2WRhd6r6HOHGqUBVZh+YKpnObZ6dmWrfUTg6eN J9dA== 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=0rqEHtyUvKInY3eDADJFtpu+gdfZq4axYpoJEFqNG8M=; b=lAQJN9YRNXlAqiwqrHC/MJqWfbRyfij8ImSuBYWbTPqnU4Jb6cKEykLmI9J+IKqXxW zzJ01rxprDfCkUAE7TU64/2aAkcpwjXut1clTuhEfoRKNWBgBYqC1xlH5LLnd33pXOOl aLYcuU391Kxp6pJe5Gsy3e5wYh+GS6jJeNYhdNYH2g/lJppLBXvRGrTKvbWmcvy4KC/Y GMN/O3YS4HZExKRzpPQFZW41r01uBus5lyoAaQbWnst7guJjH1WhI3LsatpREEkzvW2Y LmL+RHRMWXgcrQN5dWWLUyTQvBzGdu8Z90en3Zy6uTIPYzqNB9dn9f5ZmK2YmR4xvo2w c+CA== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=I2qodJt4; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-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 eb13-20020a0564020d0d00b00410d71d3f1csi10272053edb.599.2022.03.01.05.44.00; Tue, 01 Mar 2022 05:44:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-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=I2qodJt4; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235025AbiCAN22 (ORCPT + 99 others); Tue, 1 Mar 2022 08:28:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52072 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234454AbiCAN20 (ORCPT ); Tue, 1 Mar 2022 08:28:26 -0500 Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E46621815 for ; Tue, 1 Mar 2022 05:27:44 -0800 (PST) Received: by mail-il1-x12b.google.com with SMTP id k7so5528459ilo.8 for ; Tue, 01 Mar 2022 05:27:44 -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=0rqEHtyUvKInY3eDADJFtpu+gdfZq4axYpoJEFqNG8M=; b=I2qodJt4VEaNZJyZteahkXLrk3gcBP6spDM9mba7O5eU1RB0noMF3SaBN+E8vfdw3Y GW1Qja0562jHy97CnNHFiAvEnhDIzFZuk2nVuHxePbR8HX9rviCDiIna9neO0UiGoLDn jsXu+RAKBdy7qxqlxo03hClTY9xe+rR+zNfDg= 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=0rqEHtyUvKInY3eDADJFtpu+gdfZq4axYpoJEFqNG8M=; b=gOjj6VjjKLlHnekYLJkQC1U/KP9EA8EOv4crG29Wt6468tWRcwJ4Ss58ROE90cb5NM JLs6y7GdNGKLslu7PQZtpG27zw7Lygn+d6K8goHi51rUaoZM98GHK0q27JlY9oQ5K8aT Wr/F6qauPmfSx1pBP5tICvSl2gRdISeaKEust8zDYyZJLwVdLIx4YvWRGQNGQlsyJs5B xry5WSLMMQ3Lca+usMAomftog0S9eB2Su00DF+3u1wic5VbDaz1bDK14tmbqxorMQsSl e+GxGf6mktq+jIxsPwaGFytEM/wWcFohh50zchDPr/HnkJSkxvIT48UU58JUm0nAmI27 heGA== X-Gm-Message-State: AOAM533JDs5m5AeSgT/Vr5r+rn+oxWaBhU2ehYpPm6FzQVWGwZR/LiS5 YHQPFXcerTje0ETA76ApKVYm+n3Jwn/QGoOeA+UcbQ== X-Received: by 2002:a92:ca4a:0:b0:2ba:878e:fd12 with SMTP id q10-20020a92ca4a000000b002ba878efd12mr22464625ilo.139.1646141263901; Tue, 01 Mar 2022 05:27:43 -0800 (PST) MIME-Version: 1.0 References: <164549971112.9187.16871723439770288255.stgit@noble.brown> <164549983737.9187.2627117501000365074.stgit@noble.brown> In-Reply-To: <164549983737.9187.2627117501000365074.stgit@noble.brown> From: Miklos Szeredi Date: Tue, 1 Mar 2022 14:27:33 +0100 Message-ID: Subject: Re: [PATCH 04/11] fuse: remove reliance on bdi congestion 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-ext4@vger.kernel.org On Tue, 22 Feb 2022 at 04:18, NeilBrown wrote: > > The bdi congestion tracking in not widely used and will be removed. > > Fuse is one of a small number of filesystems that uses it, setting both > the sync (read) and async (write) congestion flags at what it determines > are appropriate times. > > The only remaining effect of the sync flag is to cause read-ahead to be > skipped. > The only remaining effect of the async flag is to cause (some) > WB_SYNC_NONE writes to be skipped. > > So instead of setting the flags, change: > - .readahead to stop when it has submitted all non-async pages > for read. > - .writepages to do nothing if WB_SYNC_NONE and the flag would be set > - .writepage to return AOP_WRITEPAGE_ACTIVATE if WB_SYNC_NONE > and the flag would be set. > > The writepages change causes a behavioural change in that pageout() can > now return PAGE_ACTIVATE instead of PAGE_KEEP, so SetPageActive() will > be called on the page which (I think) will further delay the next attempt > at writeout. This might be a good thing. > > Signed-off-by: NeilBrown > --- > fs/fuse/control.c | 17 ----------------- > fs/fuse/dev.c | 8 -------- > fs/fuse/file.c | 17 +++++++++++++++++ > 3 files changed, 17 insertions(+), 25 deletions(-) > > diff --git a/fs/fuse/control.c b/fs/fuse/control.c > index 000d2e5627e9..7cede9a3bc96 100644 > --- a/fs/fuse/control.c > +++ b/fs/fuse/control.c > @@ -164,7 +164,6 @@ static ssize_t fuse_conn_congestion_threshold_write(struct file *file, > { > unsigned val; > struct fuse_conn *fc; > - struct fuse_mount *fm; > ssize_t ret; > > ret = fuse_conn_limit_write(file, buf, count, ppos, &val, > @@ -178,22 +177,6 @@ static ssize_t fuse_conn_congestion_threshold_write(struct file *file, > down_read(&fc->killsb); > spin_lock(&fc->bg_lock); > fc->congestion_threshold = val; > - > - /* > - * Get any fuse_mount belonging to this fuse_conn; s_bdi is > - * shared between all of them > - */ > - > - if (!list_empty(&fc->mounts)) { > - fm = list_first_entry(&fc->mounts, struct fuse_mount, fc_entry); > - if (fc->num_background < fc->congestion_threshold) { > - clear_bdi_congested(fm->sb->s_bdi, BLK_RW_SYNC); > - clear_bdi_congested(fm->sb->s_bdi, BLK_RW_ASYNC); > - } else { > - set_bdi_congested(fm->sb->s_bdi, BLK_RW_SYNC); > - set_bdi_congested(fm->sb->s_bdi, BLK_RW_ASYNC); > - } > - } > spin_unlock(&fc->bg_lock); > up_read(&fc->killsb); > fuse_conn_put(fc); > diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c > index cd54a529460d..e1b4a846c90d 100644 > --- a/fs/fuse/dev.c > +++ b/fs/fuse/dev.c > @@ -315,10 +315,6 @@ void fuse_request_end(struct fuse_req *req) > wake_up(&fc->blocked_waitq); > } > > - if (fc->num_background == fc->congestion_threshold && fm->sb) { > - clear_bdi_congested(fm->sb->s_bdi, BLK_RW_SYNC); > - clear_bdi_congested(fm->sb->s_bdi, BLK_RW_ASYNC); > - } > fc->num_background--; > fc->active_background--; > flush_bg_queue(fc); > @@ -540,10 +536,6 @@ static bool fuse_request_queue_background(struct fuse_req *req) > fc->num_background++; > if (fc->num_background == fc->max_background) > fc->blocked = 1; > - if (fc->num_background == fc->congestion_threshold && fm->sb) { > - set_bdi_congested(fm->sb->s_bdi, BLK_RW_SYNC); > - set_bdi_congested(fm->sb->s_bdi, BLK_RW_ASYNC); > - } > list_add_tail(&req->list, &fc->bg_queue); > flush_bg_queue(fc); > queued = true; > diff --git a/fs/fuse/file.c b/fs/fuse/file.c > index 829094451774..94747bac3489 100644 > --- a/fs/fuse/file.c > +++ b/fs/fuse/file.c > @@ -966,6 +966,14 @@ static void fuse_readahead(struct readahead_control *rac) > struct fuse_io_args *ia; > struct fuse_args_pages *ap; > > + if (fc->num_background >= fc->congestion_threshold && > + rac->ra->async_size >= readahead_count(rac)) > + /* > + * Congested and only async pages left, so skip the > + * rest. > + */ > + break; Ah, you are taking care of it here... Regarding the async part: a potential (corner?) case is if task A is reading region X and triggering readahead for region Y and at the same time task B is reading region Y. In the congestion case it can happen that non-uptodate pages in Y are truncated off the pagecache while B is waiting for them to become uptodate. This shouldn't be too hard to trigger, just need two sequential readers of the same file, where one is just ahead of the other. I'll try to do a test program for this case specifically. Thanks, Miklos