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 X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3124C48BE8 for ; Fri, 18 Jun 2021 08:18:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0AC3E6120D for ; Fri, 18 Jun 2021 08:18:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0AC3E6120D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=szeredi.hu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7B22B6B0070; Fri, 18 Jun 2021 04:18:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 789366B0071; Fri, 18 Jun 2021 04:18:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6507C6B0072; Fri, 18 Jun 2021 04:18:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0033.hostedemail.com [216.40.44.33]) by kanga.kvack.org (Postfix) with ESMTP id 324EF6B0070 for ; Fri, 18 Jun 2021 04:18:34 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id BA8688249980 for ; Fri, 18 Jun 2021 08:18:33 +0000 (UTC) X-FDA: 78266142906.18.FD0CE75 Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) by imf23.hostedemail.com (Postfix) with ESMTP id E3958A000274 for ; Fri, 18 Jun 2021 08:18:32 +0000 (UTC) Received: by mail-ua1-f53.google.com with SMTP id e20so3101248ual.9 for ; Fri, 18 Jun 2021 01:18:32 -0700 (PDT) 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=K6oejrlNG6jfpvhOJUWCMjGYQKj/nTWi9Xf/F2Ug0Lg=; b=rcwqlPRWfY9G/kpL5ukEs7Y0HtIBZ0eDNR/vormpioQwGoydGvE1C2vc76tG7rf1Aj iF8K+sbzIdEQbTPB/JFbmT8E+BDVKy7Dr/cbd3iR5DA35Gk1WqRiDLk1dLNVOOuqUDfv gUrOlwjyhvW8wKlYE4km1BmasrdghOh4X7nzU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K6oejrlNG6jfpvhOJUWCMjGYQKj/nTWi9Xf/F2Ug0Lg=; b=Igoan7UNlygv0mxQMWUXgLYLJfIes6h8lSZ6n9cOT8DQKSRdJ+RZ7T3Je0AOoWCiwQ UFUwk0v/LSZImEBDMZgIJ7tIKFUidJPbiodB0NBT1pKw+7Ybvrh1FlUqgMqGk9bn26Y2 yVvAPikjJ4FjnjA6FEXMc+tCeIcJwaMlhahkn0lcOIo65Trm5fo98B2bX8KPszs8SGyv CDY/MYPZ7ebW+2awFsjqQXUWyUCa/PVXZovjM3dGZwbLQh5fZ3GWwEiW/gDR6QBpy0Wh WUX6jDJ0f3Rrat1gQjFR5zrGtcXguW127L9IVdrYlSUb2NXIo3raFvSaibYlpqBAuCCb zkhA== X-Gm-Message-State: AOAM5316VX9c9LMI1lDYgUbLHxToLEXvwue4jN/dQxdvnoV0GL7S/GyD TAGdVwQfxbaxdetoUd42760GpZGnUWXEahiJtMdkLg== X-Google-Smtp-Source: ABdhPJwMr7bKbHnJ4J222POIdgpQ6O6/jjmoMsvlx6MPZxuQgKtceEK7VsPlh5QYDSIqOGlKqJ6m2KLCMcki/QSUulo= X-Received: by 2002:ab0:3418:: with SMTP id z24mr10555190uap.11.1624004312143; Fri, 18 Jun 2021 01:18:32 -0700 (PDT) MIME-Version: 1.0 References: <20210617095309.3542373-1-stapelberg+linux@google.com> In-Reply-To: <20210617095309.3542373-1-stapelberg+linux@google.com> From: Miklos Szeredi Date: Fri, 18 Jun 2021 10:18:21 +0200 Message-ID: Subject: Re: [PATCH] backing_dev_info: introduce min_bw/max_bw limits To: Michael Stapelberg Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm , linux-fsdevel@vger.kernel.org, Tejun Heo , Dennis Zhou , Jens Axboe , Roman Gushchin , Johannes Thumshirn , Jan Kara , Song Liu , David Sterba Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: E3958A000274 X-Stat-Signature: cgr1edqf3uidgdj7xw7nhyttex1rn9ot Authentication-Results: imf23.hostedemail.com; dkim=none ("invalid DKIM record") header.d=szeredi.hu header.s=google header.b=rcwqlPRW; dmarc=none; spf=pass (imf23.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.222.53 as permitted sender) smtp.mailfrom=miklos@szeredi.hu X-HE-Tag: 1624004312-942175 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000252, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 17 Jun 2021 at 11:53, Michael Stapelberg wrote: > > These new knobs allow e.g. FUSE file systems to guide kernel memory > writeback bandwidth throttling. > > Background: > > When using mmap(2) to read/write files, the page-writeback code tries to > measure how quick file system backing devices (BDI) are able to write data, > so that it can throttle processes accordingly. > > Unfortunately, certain usage patterns, such as linkers (tested with GCC, > but also the Go linker) seem to hit an unfortunate corner case when writing > their large executable output files: the kernel only ever measures > the (non-representative) rising slope of the starting bulk write, but the > whole file write is already over before the kernel could possibly measure > the representative steady-state. > > As a consequence, with each program invocation hitting this corner case, > the FUSE write bandwidth steadily sinks in a downward spiral, until it > eventually reaches 0 (!). This results in the kernel heavily throttling > page dirtying in programs trying to write to FUSE, which in turn manifests > itself in slow or even entirely stalled linker processes. > > Change: > > This commit adds 2 knobs which allow avoiding this situation entirely on a > per-file-system basis by restricting the minimum/maximum bandwidth. This looks like a bug in the dirty throttling heuristics, that may be effecting multiple fuse based filesystems. Ideally the solution should be a fix to those heuristics, not adding more knobs. Is there a fundamental reason why that can't be done? Maybe the heuristics need to detect the fact that steady state has not been reached, and not modify the bandwidth in that case, or something along those lines. Thanks, Miklos