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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 A8570C48BDF for ; Fri, 18 Jun 2021 14:42:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2138B611CD for ; Fri, 18 Jun 2021 14:42:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2138B611CD 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 9AAAD6B006E; Fri, 18 Jun 2021 10:42:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9816E6B0071; Fri, 18 Jun 2021 10:42:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 849186B0072; Fri, 18 Jun 2021 10:42:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0237.hostedemail.com [216.40.44.237]) by kanga.kvack.org (Postfix) with ESMTP id 56DE76B006E for ; Fri, 18 Jun 2021 10:42:11 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E393BDE1F for ; Fri, 18 Jun 2021 14:42:10 +0000 (UTC) X-FDA: 78267109620.38.AC3A9A6 Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) by imf28.hostedemail.com (Postfix) with ESMTP id A18212001102 for ; Fri, 18 Jun 2021 14:42:08 +0000 (UTC) Received: by mail-ua1-f47.google.com with SMTP id e20so3471099ual.9 for ; Fri, 18 Jun 2021 07:42:09 -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:content-transfer-encoding; bh=nqlCd2eHu+FNO0OH2gW6QkHD4Px5yMOfqRW26XQAK2o=; b=kYhMqUnz83h3s/37sIDv6unVm3hgmAnDw21NoXLxZpBiEwBC4HQ+gGAsfPYatAsbuA X6IEjDZiJzyns2/lnFDnsJqMlW113kPs5bpoxHBn/CzbOfrqQyh9d84b9u1Mffj/ekUZ pAWAT6WofHxbRthUqO1Wercd8AhpTrNpbSfLM= 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:content-transfer-encoding; bh=nqlCd2eHu+FNO0OH2gW6QkHD4Px5yMOfqRW26XQAK2o=; b=j/bIQ6AIvfVvG1k6gVKOtMWFYOCf0iPii71wH+7MEcy4RRdfX2GGmijN6raOck+UMw nl/C7K9NoFwG1B5IYXpg1IODzg3gnCMDKF9jzioOrfEB1AhX/UUQLqQKhI0stIdCV4KU O4OirkqVbARyOSfYPsEWafT/7/mkTWBj25y6LxQPqDe9bMs3MPftnkeLfjmfIPhhugl4 I3yFwxCuLJLybPehSmMY6YpqTg4xSrILxZpo3LniT0R1QImW4onRxQykOrk8axnLOoT8 7S3DThU/JTdyrBnTj7vFKfOeCRxJCCpkZOYQBz2JUvDD4tcHRowDiNzry69W1sml1Qud FRBg== X-Gm-Message-State: AOAM531yV24wYW52q+AhbyUyptWLeY2QWzp/VWU+BfP0fTGnIclc0uWJ hAjlHI8hh4yfRJVR/EqvlWKo+5wWWuqTlVqcOCNHdg== X-Google-Smtp-Source: ABdhPJxCPhcUp8VAgjMWYNQ+3Qh6e+CuVyciWjfH2mFAT6A530O3DOsPQ0ktvjy3CnVHRYCPNLlXR3q0wOPmds5CHuM= X-Received: by 2002:ab0:6448:: with SMTP id j8mr12732714uap.13.1624027329045; Fri, 18 Jun 2021 07:42:09 -0700 (PDT) MIME-Version: 1.0 References: <20210617095309.3542373-1-stapelberg+linux@google.com> In-Reply-To: From: Miklos Szeredi Date: Fri, 18 Jun 2021 16:41:58 +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" Content-Transfer-Encoding: quoted-printable Authentication-Results: imf28.hostedemail.com; dkim=none ("invalid DKIM record") header.d=szeredi.hu header.s=google header.b=kYhMqUnz; dmarc=none; spf=pass (imf28.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.222.47 as permitted sender) smtp.mailfrom=miklos@szeredi.hu X-Rspamd-Server: rspam02 X-Stat-Signature: p65tbtqagj3gm9d4k7ahus38dkr8cmi3 X-Rspamd-Queue-Id: A18212001102 X-HE-Tag: 1624027328-60489 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000534, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 18 Jun 2021 at 10:31, Michael Stapelberg wrote: > Maybe, but I don=E2=80=99t have the expertise, motivation or time to > investigate this any further, let alone commit to get it done. > During our previous discussion I got the impression that nobody else > had any cycles for this either: > https://lore.kernel.org/linux-fsdevel/CANnVG6n=3DySfe1gOr=3D0ituQidp56idG= ARDKHzP0hv=3DERedeMrMA@mail.gmail.com/ > > Have you had a look at the China LSF report at > http://bardofschool.blogspot.com/2011/? > The author of the heuristic has spent significant effort and time > coming up with what we currently have in the kernel: > > """ > Fengguang said he draw more than 10K performance graphs and read even > more in the past year. > """ > > This implies that making changes to the heuristic will not be a quick fix= . Having a piece of kernel code sitting there that nobody is willing to fix is certainly not a great situation to be in. And introducing band aids is not going improve the above situation, more likely it will prolong it even further. Thanks, Miklos