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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0B20C433F5 for ; Fri, 28 Jan 2022 09:38:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229836AbiA1JiQ (ORCPT ); Fri, 28 Jan 2022 04:38:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59502 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347685AbiA1JiN (ORCPT ); Fri, 28 Jan 2022 04:38:13 -0500 Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B471C061753 for ; Fri, 28 Jan 2022 01:38:08 -0800 (PST) Received: by mail-vs1-xe30.google.com with SMTP id v62so2281245vsv.4 for ; Fri, 28 Jan 2022 01:38:08 -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=E/VIyc5JpK2Sy5loT9a2HcHWg2TrorJJxRaogeKP25w=; b=EibPllimp8WZIwxJdUGUIFAlIuZdyznPvrXJ7caP5EDkiBNUVM4ihiUoIfNxC6TVSx YE207qfvpl7N/VHWz1SefuMcAFD5mqGieRSegzXNyYGWfyIdkPkwWByrIvqWimbKQ8Un /lbUGxvPlDX06Jf/32nPUu5Q90vZSrQ0/ovfo= 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=E/VIyc5JpK2Sy5loT9a2HcHWg2TrorJJxRaogeKP25w=; b=2lqyyHONhyBYvm+6hB88VYG3UEW46bGepLcEQXFnC/4kZcx/w4yhIoVJ1WlAuUx1e8 JaBNxtdEHZsR0oeyBTE2kqUF12BSg2vfMCrmepKtK/D4854ut8mGHb06QoFk1dUI+U0V fTsbVfdq7bW5pZYb1apMK1zwhNiXTy1pv5ud8o3WDZ5MDOKGrR01re52ULN3nEYtPf/g Dybb9FyUAS9wsVOw7KbRzyLLO1clACbB1vbqfBG2o/eVjMJkt8XK+uLN5uReqDlqbDjF 7aVuB71qdDfCcmTTNuv848+825GnCfoYiGwgp6z855x9AjtPUglpRXV4wwSsHsax9ALp qCnQ== X-Gm-Message-State: AOAM533dtkbSEXBnBIGlOSoBoqb8JE/ggp+fyZlV5+dHGV23kRp8Gggh bMMzy7P+L6t4BIoZdBeJXvrVs3KD4Rex3E+uqY1RXcIvN1LNoQ== X-Google-Smtp-Source: ABdhPJwGf3F8vVWMx/hAPOM/tzuC6mlnTkkNvV3zFtYKADK7sTRpnxjvKNE9DMzHauL+NEVwnl4j38I6/K9jRDhQk7E= X-Received: by 2002:a67:c390:: with SMTP id s16mr3769368vsj.61.1643362687362; Fri, 28 Jan 2022 01:38:07 -0800 (PST) MIME-Version: 1.0 References: <164325106958.29787.4865219843242892726.stgit@noble.brown> <164325158954.29787.7856652136298668100.stgit@noble.brown> In-Reply-To: <164325158954.29787.7856652136298668100.stgit@noble.brown> From: Miklos Szeredi Date: Fri, 28 Jan 2022 10:37:56 +0100 Message-ID: Subject: Re: [PATCH 1/9] Remove inode_congested() To: NeilBrown Cc: Andrew Morton , 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-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, linux-block@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Thu, 27 Jan 2022 at 03:47, NeilBrown wrote: > > inode_congested() reports if the backing-device for the inode is > congested. Few bdi report congestion any more, only ceph, fuse, and > nfs. Having support just for those is unlikely to be useful. > > The places which test inode_congested() or it variants like > inode_write_congested(), avoid initiating IO if congestion is present. > We now have to rely on other places in the stack to back off, or abort > requests - we already do for everything except these 3 filesystems. > > So remove inode_congested() and related functions, and remove the call > sites, assuming that inode_congested() always returns 'false'. Looks to me this is going to "break" fuse; e.g. readahead path will go ahead and try to submit more requests, even if the queue is getting congested. In this case the readahead submission will eventually block, which is counterproductive. I think we should *first* make sure all call sites are substituted with appropriate mechanisms in the affected filesystems and as a last step remove the superfluous bdi congestion mechanism. You are saying that all fs except these three already have such mechanisms in place, right? Can you elaborate on that? Thanks, Miklos 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 lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0AC27C4332F for ; Fri, 28 Jan 2022 11:10:40 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.94.2) (envelope-from ) id 1nDP9K-0005q0-2t; Fri, 28 Jan 2022 11:10:36 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nDP9H-0005pu-R8 for linux-f2fs-devel@lists.sourceforge.net; Fri, 28 Jan 2022 11:10:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Type:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=E/VIyc5JpK2Sy5loT9a2HcHWg2TrorJJxRaogeKP25w=; b=DvF9lrTsEYYowgwgkZngtpXt55 ubMLc32hGlFIM56nag9Rz4KNWAw8SYLjgkszBDl+hCH1L4DFVxRi7tO4SQfK3Y/168xWuzp9R6nu7 ujb6OMYzxFWxi4tLIRimS8PRt/bLaOVtyGzACoORqXR9GqjT7dA7C3BFW6ZsCYDJMm+Q=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References: MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=E/VIyc5JpK2Sy5loT9a2HcHWg2TrorJJxRaogeKP25w=; b=DlyfyLM6kblFBPlrQKJ5XBs3X2 CuKbqhy9cHna8TU+tVU92jTFr64qieei7Z9icVuOZ2Tzs2TrYpE1NpwEor9WM6kGhYUSmSEhRoPdx +5bdHxitSU0WsUvXTJcIKCE84OmGSr2N0Lp6bM9Wd4Zo32qWbTh89QST95Q1CUdruMZg=; Received: from mail-vk1-f175.google.com ([209.85.221.175]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.94.2) id 1nDP9C-0004Jb-L2 for linux-f2fs-devel@lists.sourceforge.net; Fri, 28 Jan 2022 11:10:34 +0000 Received: by mail-vk1-f175.google.com with SMTP id l196so3654740vki.5 for ; Fri, 28 Jan 2022 03:10:30 -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=E/VIyc5JpK2Sy5loT9a2HcHWg2TrorJJxRaogeKP25w=; b=EibPllimp8WZIwxJdUGUIFAlIuZdyznPvrXJ7caP5EDkiBNUVM4ihiUoIfNxC6TVSx YE207qfvpl7N/VHWz1SefuMcAFD5mqGieRSegzXNyYGWfyIdkPkwWByrIvqWimbKQ8Un /lbUGxvPlDX06Jf/32nPUu5Q90vZSrQ0/ovfo= 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=E/VIyc5JpK2Sy5loT9a2HcHWg2TrorJJxRaogeKP25w=; b=3oSWhqLa6Sg4fdXbXTbq1xsXaNo44I7vl9pArWw6R0Eg771X1VmAssGKA8jtSzOl5R BDkloZl8MngJwI+gVudhSsl3AkERIvSgFPXTM/kKEH85jq4xfxOUsdv1jDDrb+raJMvt YEwgDn36Wk7ENvpuhGZUCB7BATYdA2KalK0dJt94FI/bkorGfR/O2pGtXW2DhAHhnNAO 3QFbgH1LyOIoiImG51Qv7IrnEcN2jRE3n/3KI+zZMKrZ1CEs5PyVroRQ0QJcg9HWKWMk s3mapP1OLIiz5hBT11s3VTiUzbRSsNz4kqRrms2ksl5dZRoNRkMSgU0xV4z5eutxr1oF tl3g== X-Gm-Message-State: AOAM532EuE81YlUuG2gRSwgMEAly07cTOkEzzUS8haaU94I282xfhkF6 7pHz0WS/2KJNmnDDjupSr4uoK9xUtBRydh3NGnyXcw0GOQhSYQ== X-Google-Smtp-Source: ABdhPJwGf3F8vVWMx/hAPOM/tzuC6mlnTkkNvV3zFtYKADK7sTRpnxjvKNE9DMzHauL+NEVwnl4j38I6/K9jRDhQk7E= X-Received: by 2002:a67:c390:: with SMTP id s16mr3769368vsj.61.1643362687362; Fri, 28 Jan 2022 01:38:07 -0800 (PST) MIME-Version: 1.0 References: <164325106958.29787.4865219843242892726.stgit@noble.brown> <164325158954.29787.7856652136298668100.stgit@noble.brown> In-Reply-To: <164325158954.29787.7856652136298668100.stgit@noble.brown> From: Miklos Szeredi Date: Fri, 28 Jan 2022 10:37:56 +0100 Message-ID: To: NeilBrown X-Headers-End: 1nDP9C-0004Jb-L2 Subject: Re: [f2fs-dev] [PATCH 1/9] Remove inode_congested() X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Darrick J. Wong" , linux-kernel@vger.kernel.org, linux-mm , drbd-dev@lists.linbit.com, Paolo Valente , Trond Myklebust , Ilya Dryomov , Ext4 , linux-block@vger.kernel.org, linux-nilfs@vger.kernel.org, Jaegeuk Kim , ceph-devel@vger.kernel.org, Ryusuke Konishi , Jens Axboe , Linux NFS list , Andrew Morton , Jeff Layton , Philipp Reisner , linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, Lars Ellenberg , Anna Schumaker Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Thu, 27 Jan 2022 at 03:47, NeilBrown wrote: > > inode_congested() reports if the backing-device for the inode is > congested. Few bdi report congestion any more, only ceph, fuse, and > nfs. Having support just for those is unlikely to be useful. > > The places which test inode_congested() or it variants like > inode_write_congested(), avoid initiating IO if congestion is present. > We now have to rely on other places in the stack to back off, or abort > requests - we already do for everything except these 3 filesystems. > > So remove inode_congested() and related functions, and remove the call > sites, assuming that inode_congested() always returns 'false'. Looks to me this is going to "break" fuse; e.g. readahead path will go ahead and try to submit more requests, even if the queue is getting congested. In this case the readahead submission will eventually block, which is counterproductive. I think we should *first* make sure all call sites are substituted with appropriate mechanisms in the affected filesystems and as a last step remove the superfluous bdi congestion mechanism. You are saying that all fs except these three already have such mechanisms in place, right? Can you elaborate on that? Thanks, Miklos _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miklos Szeredi Subject: Re: [PATCH 1/9] Remove inode_congested() Date: Fri, 28 Jan 2022 10:37:56 +0100 Message-ID: References: <164325106958.29787.4865219843242892726.stgit@noble.brown> <164325158954.29787.7856652136298668100.stgit@noble.brown> Mime-Version: 1.0 Return-path: 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=E/VIyc5JpK2Sy5loT9a2HcHWg2TrorJJxRaogeKP25w=; b=EibPllimp8WZIwxJdUGUIFAlIuZdyznPvrXJ7caP5EDkiBNUVM4ihiUoIfNxC6TVSx YE207qfvpl7N/VHWz1SefuMcAFD5mqGieRSegzXNyYGWfyIdkPkwWByrIvqWimbKQ8Un /lbUGxvPlDX06Jf/32nPUu5Q90vZSrQ0/ovfo= In-Reply-To: <164325158954.29787.7856652136298668100.stgit@noble.brown> List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: NeilBrown Cc: Andrew Morton , 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-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 On Thu, 27 Jan 2022 at 03:47, NeilBrown wrote: > > inode_congested() reports if the backing-device for the inode is > congested. Few bdi report congestion any more, only ceph, fuse, and > nfs. Having support just for those is unlikely to be useful. > > The places which test inode_congested() or it variants like > inode_write_congested(), avoid initiating IO if congestion is present. > We now have to rely on other places in the stack to back off, or abort > requests - we already do for everything except these 3 filesystems. > > So remove inode_congested() and related functions, and remove the call > sites, assuming that inode_congested() always returns 'false'. Looks to me this is going to "break" fuse; e.g. readahead path will go ahead and try to submit more requests, even if the queue is getting congested. In this case the readahead submission will eventually block, which is counterproductive. I think we should *first* make sure all call sites are substituted with appropriate mechanisms in the affected filesystems and as a last step remove the superfluous bdi congestion mechanism. You are saying that all fs except these three already have such mechanisms in place, right? Can you elaborate on that? Thanks, Miklos