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 893A4C433EF for ; Mon, 31 Jan 2022 10:21:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B5A126B0071; Mon, 31 Jan 2022 05:21:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B0A6A6B0073; Mon, 31 Jan 2022 05:21:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F9336B0074; Mon, 31 Jan 2022 05:21:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0024.hostedemail.com [216.40.44.24]) by kanga.kvack.org (Postfix) with ESMTP id 8C7376B0071 for ; Mon, 31 Jan 2022 05:21:36 -0500 (EST) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 4703B18210E96 for ; Mon, 31 Jan 2022 10:21:36 +0000 (UTC) X-FDA: 79090190592.31.5612A3B Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) by imf21.hostedemail.com (Postfix) with ESMTP id 7FAF21C000E for ; Mon, 31 Jan 2022 10:21:35 +0000 (UTC) Received: by mail-vk1-f176.google.com with SMTP id w17so7921740vko.9 for ; Mon, 31 Jan 2022 02:21:34 -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=3Lm3cgz6DtmL9tpisEfrfuo7Wj8QCaI1ocVGLYB2Y2U=; b=Lind02/Njzrr7eWAupL32iIHm4GhlbxdTkXaEnTW2OV0dgNWX/rudjG6+pcPbPpIFq C69XJIFu0uAQHgKg9yzKqDEaKe2dTryF/XVS7u5Fs51eNy1ypgdGDsx2HWFQUKmKA/Qj gsFWvFnWm3m6cKgmcrNeOadSQiHcKT9p9vJ3c= 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=3Lm3cgz6DtmL9tpisEfrfuo7Wj8QCaI1ocVGLYB2Y2U=; b=mKUJLflxVV4rVAL/GM7D82JGCRJwSXfReJJJUXmCHHru/eKMxTHRj5qXlDuUzSc9K7 LZ0krnd5dwmWnZ1LGra79Pix79DfLAw4/LaACSVRWzDtkF1hZ5DpG4o84okBOyA1piPy C7QKg8ZlPo+mg1PjKIqJDyJEK32OX8Q7qf8ROa6Beh/Sk1nfwphZexE4H04tlsmQ1BSq DoZq+kxOeAyQoA8S0w2s+0McI/s0M0LGW4MxraJONqAj8NYlw0HNHGTYnU9HSdoTnPhW b7JA+y4r5piXrxkJsuPnLqQtGhT8Iki4D6Ksze5AniGWkZvxYtV7VXF3SNipRzbWikB7 MYhQ== X-Gm-Message-State: AOAM531lj/F7JK9R+IiF5N/eaTPvSi883o6MEDogxNF+zYM15tj27PGx ETm8hwSSFzeIUO7CT55IPIyONKiBOAiKHKOkvI3JtA== X-Google-Smtp-Source: ABdhPJwOQtCABzU+9UXwt+UwQamDQBcR3aBXOuhKxfwoBl2Am0C/bqSbVLQ7zPuyDB0UYMDY2raQ+Hlv8DNEyXB5kK8= X-Received: by 2002:a1f:a753:: with SMTP id q80mr8215440vke.1.1643624494313; Mon, 31 Jan 2022 02:21:34 -0800 (PST) MIME-Version: 1.0 References: <164360127045.4233.2606812444285122570.stgit@noble.brown> <164360183348.4233.761031466326833349.stgit@noble.brown> <164360446180.18996.6767388833611575467@noble.neil.brown.name> In-Reply-To: <164360446180.18996.6767388833611575467@noble.neil.brown.name> From: Miklos Szeredi Date: Mon, 31 Jan 2022 11:21:23 +0100 Message-ID: Subject: Re: [PATCH 1/3] fuse: remove reliance on bdi congestion To: NeilBrown Cc: Matthew Wilcox , Andrew Morton , Jeff Layton , Ilya Dryomov , Trond Myklebust , Anna Schumaker , linux-mm , Linux NFS list , linux-fsdevel@vger.kernel.org, ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: prsnj1p6je3766goh4zouq9z9r13pift X-Rspam-User: nil Authentication-Results: imf21.hostedemail.com; dkim=none ("invalid DKIM record") header.d=szeredi.hu header.s=google header.b="Lind02/N"; spf=pass (imf21.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.221.176 as permitted sender) smtp.mailfrom=miklos@szeredi.hu; dmarc=none X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 7FAF21C000E X-HE-Tag: 1643624495-681470 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 Mon, 31 Jan 2022 at 05:47, NeilBrown wrote: > > > +++ b/fs/fuse/file.c > > > @@ -958,6 +958,8 @@ static void fuse_readahead(struct readahead_control *rac) > > > > > > if (fuse_is_bad(inode)) > > > return; > > > + if (fc->num_background >= fc->congestion_threshold) > > > + return; > > > > This seems like a bad idea to me. If we don't even start reads on > > readahead pages, they'll get ->readpage called on them one at a time > > and the reading thread will block. It's going to lead to some nasty > > performance problems, exactly when you don't want them. Better to > > queue the reads internally and wait for congestion to ease before > > submitting the read. > > > > Isn't that exactly what happens now? page_cache_async_ra() sees that > inode_read_congested() returns true, so it doesn't start readahead. > ??? I agree. Fuse throttles async requests even before allocating them, which precludes placing them on any queue. I guess it was done to limit the amount of kernel memory pinned by a task (sync requests allow just one request per task). This has worked well, and I haven't heard complaints about performance loss due to readahead throttling. Thanks, Miklos