Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp1135546ybh; Sat, 3 Aug 2019 18:51:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqyLj9GkBwxFKAXCgaCcStMi5uypyGqwNWv7DhXM3XCHAGgrjzAkfi9MbAtArFnmHMcFuHwu X-Received: by 2002:a62:2784:: with SMTP id n126mr67903377pfn.61.1564883466590; Sat, 03 Aug 2019 18:51:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564883466; cv=none; d=google.com; s=arc-20160816; b=S0g3j81cgrMdwH76ju67UgPloeT/Ntu855rh+uo8hOocCEbnwwn9UhlrCtcK0FYVvq O8r7sW8D+FKg22JNZuFux0lIOhgPlr4q7yNdyw26EjAZXHRDE0IXRh9uHHynRdLUBdCe +/ePw56Kj7hju2mje5Y4XrD/doU6uMi9DbIZ187zx8V4Vh4/Za9xq5HNVfC8ggZgYU35 yHXXUUOM9rwYRUgXTdKJnHuyz2giU+2av5bWoxlvxZVpSfkSQalZ7Fp6n55kA+GeFeGf W6HhNSwAm3GXRqRJNTMLJab7uwchI3pBJs/gvcmecfkR6T8axctscqTjfcnEZyUDrdaW t4mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=bg0IYF6s1vKTQqCOaTbUbf6y5ZEAOUzglk0PVhrL/38=; b=bGMlGVGvhzmnYOtPkkB7gODVGAW+g0lKO2ooPsA/J3OhVRQkQIRfYe+1AYjy5czX42 bjk5hRV2SyMIxYenoEGPsEawwL+vpFbdh7lnaDjXnF1H0r8AyrdYg1tyMqqUc3fuI6uv MiX2K6wyOjv7mYap9epGiI8jcka9WqSsHp7zNnWEKR0qlQ/PL3JnHqVrVmEWcrOto8C7 aqqIPLOEdXhpneVAwyRyqnF9CwWyLqfv7TSOiY4CsEdUZLGmS3pLeYYwc1JouFJpg2Y/ ueDZhyU09BH//OjLEsR3HUpoKEVKUQrYpqQ+uxrxvFKpvrw5QIusltjxp3LdK5wGqJs8 yZWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=glnSl1NW; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t3si37786420plz.101.2019.08.03.18.50.50; Sat, 03 Aug 2019 18:51:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=glnSl1NW; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391706AbfHBTIR (ORCPT + 99 others); Fri, 2 Aug 2019 15:08:17 -0400 Received: from mail-qk1-f194.google.com ([209.85.222.194]:35040 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725866AbfHBTIQ (ORCPT ); Fri, 2 Aug 2019 15:08:16 -0400 Received: by mail-qk1-f194.google.com with SMTP id r21so55700912qke.2; Fri, 02 Aug 2019 12:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=bg0IYF6s1vKTQqCOaTbUbf6y5ZEAOUzglk0PVhrL/38=; b=glnSl1NWmZ0mA06pxO5NHcGHYLGSDwCYCk/lpygM3hxebdjzwZ5c9BT/0rVS0KRQSO vqi0RMww/iVfyDm53cDgznuv6lJmZSUElxWkFtkwGBC7HXv3MauHjfH1kZBfVno4qqNq Y/5L6tSxXegWmVMoAF0PLhqqO3NaA7vZqe3ZDaEmNZAMRViBgsk1i7sHYjxg4jXlzglN WRkJ1GC+jvZEpr424Rs9LV5Fa6L6Se02pQ8Dkpy4UeuLVvaOmsMnhyY4rrwIr4Cu/34D XatcJnT31nWYAqOxuQhEGnwi/uBE6DuFDvgUaJkBgkrtbHkKL4UG5rFY42lGVPdLUqce OZmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=bg0IYF6s1vKTQqCOaTbUbf6y5ZEAOUzglk0PVhrL/38=; b=JIQyOYoBxwwCNCrndDlVUm/zFOiJv8xu8REDo9TBH/QFAwtVxYaq2QUhYmmmE5QR+a drbFc72oYjUBzNe61pnNLNZCittnoRswO/EzyQ16Q5zuo7MVRF2HzEp7E+1gvONf96uk Ebtu7SIa+6219eyRU+VYdfc2y4BmBNWxRjcMaxoW+qZ0aZefGGKSaFlhaB63LHHW6reo K6slMZCxn/REinQFhF/OeFX4FO2e1lxWbK8jyMd2Z2/Gx4oBOnZfaaK3g1vRuZXAPnu0 uOuLOc3G81P+V7Og5Aa4wsEqOwbaUtSH2L+84M9QbqLtrY1N78L3jTeMVgUlVDkZUNdt +Rbw== X-Gm-Message-State: APjAAAUx8tmiuD0i9R6u2QZwmbSCKZSQEM3ngAy8y9H5oW2khjWyQQOv 7f94xBEtJ6sNNs73e9VpTfI= X-Received: by 2002:a37:a142:: with SMTP id k63mr8115850qke.278.1564772895730; Fri, 02 Aug 2019 12:08:15 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::38f0]) by smtp.gmail.com with ESMTPSA id f25sm38408246qta.81.2019.08.02.12.08.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Aug 2019 12:08:15 -0700 (PDT) Date: Fri, 2 Aug 2019 12:08:13 -0700 From: Tejun Heo To: Jens Axboe , Jan Kara Cc: linux-block@vger.kernel.org, kernel-team@fb.com, linux-kernel@vger.kernel.org Subject: [PATCH block 2/2] writeback, cgroup: inode_switch_wbs() shouldn't give up on wb_switch_rwsem trylock fail Message-ID: <20190802190813.GC136335@devbig004.ftw2.facebook.com> References: <20190802190738.GB136335@devbig004.ftw2.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190802190738.GB136335@devbig004.ftw2.facebook.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org As inode wb switching may make sync(2) miss some inodes, they're synchronized using wb_switch_rwsem so that no wb switching happens while sync(2) is in progress. In addition to synchronizing the actual switching, the rwsem is also used to prevent queueing new switch attempts while sync(2) is in progress. This is to avoid queueing too many instances while the rwsem is held by sync(2). Unfortunately, this is too agressive and can block wb switching for a long time if sync(2) is frequent. The goal is avoiding expolding the number of scheduled switches, not avoiding scheduling anything. Let's use wb_switch_rwsem only for synchronizing the actual switching and sync(2) and use isw_nr_in_flight instead for limiting the maximum number of scheduled switches. The limit is set to 1024 which should be more than enough while still avoiding extreme situations. Signed-off-by: Tejun Heo --- fs/fs-writeback.c | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-) --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -237,6 +237,7 @@ static void wb_wait_for_completion(struc /* if foreign slots >= 8, switch */ #define WB_FRN_HIST_MAX_SLOTS (WB_FRN_HIST_THR_SLOTS / 2 + 1) /* one round can affect upto 5 slots */ +#define WB_FRN_MAX_IN_FLIGHT 1024 /* don't queue too many concurrently */ static atomic_t isw_nr_in_flight = ATOMIC_INIT(0); static struct workqueue_struct *isw_wq; @@ -489,18 +490,13 @@ static void inode_switch_wbs(struct inod if (inode->i_state & I_WB_SWITCH) return; - /* - * Avoid starting new switches while sync_inodes_sb() is in - * progress. Otherwise, if the down_write protected issue path - * blocks heavily, we might end up starting a large number of - * switches which will block on the rwsem. - */ - if (!down_read_trylock(&bdi->wb_switch_rwsem)) + /* avoid queueing a new switch if too many are already in flight */ + if (atomic_read(&isw_nr_in_flight) > WB_FRN_MAX_IN_FLIGHT) return; isw = kzalloc(sizeof(*isw), GFP_ATOMIC); if (!isw) - goto out_unlock; + return; /* find and pin the new wb */ rcu_read_lock(); @@ -534,15 +530,12 @@ static void inode_switch_wbs(struct inod call_rcu(&isw->rcu_head, inode_switch_wbs_rcu_fn); atomic_inc(&isw_nr_in_flight); - - goto out_unlock; + return; out_free: if (isw->new_wb) wb_put(isw->new_wb); kfree(isw); -out_unlock: - up_read(&bdi->wb_switch_rwsem); } /**