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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 99704C433FE for ; Fri, 11 Dec 2020 16:56:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5F4B42310E for ; Fri, 11 Dec 2020 16:56:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729967AbgLKP4Z (ORCPT ); Fri, 11 Dec 2020 10:56:25 -0500 Received: from mx2.suse.de ([195.135.220.15]:49952 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390440AbgLKP4H (ORCPT ); Fri, 11 Dec 2020 10:56:07 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 42255AB8A; Fri, 11 Dec 2020 15:55:26 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 01B37DA6E9; Fri, 11 Dec 2020 16:53:48 +0100 (CET) Date: Fri, 11 Dec 2020 16:53:48 +0100 From: David Sterba To: Johannes Thumshirn Cc: Sidong Yang , "linux-btrfs@vger.kernel.org" Subject: Re: [PATCH] btrfs-progs: scrub: warn if scrub started on a device has mq-deadline Message-ID: <20201211155348.GK6430@suse.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Johannes Thumshirn , Sidong Yang , "linux-btrfs@vger.kernel.org" References: <20201205184929.22412-1-realwakka@gmail.com> <20201210202020.GH6430@twin.jikos.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Fri, Dec 11, 2020 at 06:50:23AM +0000, Johannes Thumshirn wrote: > On 10/12/2020 21:22, David Sterba wrote: > > On Mon, Dec 07, 2020 at 07:23:03AM +0000, Johannes Thumshirn wrote: > >> On 05/12/2020 19:51, Sidong Yang wrote: > >>> Warn if scurb stared on a device that has mq-deadline as io-scheduler > >>> and point documentation. mq-deadline doesn't work with ionice value and > >>> it results performance loss. This warning helps users figure out the > >>> situation. This patch implements the function that gets io-scheduler > >>> from sysfs and check when scrub stars with the function. > >> > >> From a quick grep it seems to me that only bfq is supporting ioprio settings. > > > > Yeah it's only BFQ. > > > >> Also there's some features like write ordering guarantees that currently > >> only mq-deadline provides. > >> > >> This warning will trigger a lot once the zoned patchset for btrfs is merged, > >> as for example SMR drives need this ordering guarantees and therefore select > >> mq-deadline (via the ELEVATOR_F_ZBD_SEQ_WRITE elevator feature). > > > > This won't affect the default case and for zoned fs we can't simply use > > BFQ and thus the ionice interface. Which should be IMHO acceptable. > > But then the patch must check if bfq is set and otherwise warn. My only fear > is though, people will blindly select bfq then and get all kinds of > penalties/problems. Hm right, and we know that once such recommendations stick, it's very hard to get rid of them even if there's a proper solution implemented. > And it's not only mq-deadline and bfq here, there are also > kyber and none. On a decent nvme I'd like to have none instead of bfq, otherwise > performance goes down the drain. If my workload is sensitive to buffer bloat, I'd > use kyber not bfq. I'm not sure about high performance devices if the scrub io load on the normal priority is the same problem as with spinning devices. Assuming it is, we need some low priority/idle class for all schedulers at least. > So IMHO this patch just makes things worse. But who am I to judge. In this situation we need broader perspective, thanks for the input, we'll hopefully come to some conclusion. We don't want to make things worse, now we're left with workarounds or warnings until some brave soul implements the missing io scheduler functionality.