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 CD505C433FE for ; Fri, 11 Nov 2022 17:30:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3FD6A8E0003; Fri, 11 Nov 2022 12:30:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3AD006B0087; Fri, 11 Nov 2022 12:30:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2749F8E0003; Fri, 11 Nov 2022 12:30:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 17B846B0085 for ; Fri, 11 Nov 2022 12:30:18 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9F69BAB0C0 for ; Fri, 11 Nov 2022 17:30:17 +0000 (UTC) X-FDA: 80121850074.12.D1F4C6B Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) by imf25.hostedemail.com (Postfix) with ESMTP id DB993A000B for ; Fri, 11 Nov 2022 17:30:16 +0000 (UTC) Received: by mail-io1-f46.google.com with SMTP id e189so4036712iof.1 for ; Fri, 11 Nov 2022 09:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=aXO456qaOP1M3JsJcts4UFcPXUKgBOMxL23ZB0rcMw4=; b=mLUwO6TqDtBXzrrFM3raYJ5s/voj/2CABngLl5kEgbmXx5H27xhERtZwmg/2tTy1rM P2syluaiRg3QUpYU3CGNrPSdu5kOIvRHN6hshAseVDet22qLw2jmTTD17V3YBIcMN7e/ vcynmeB2okCNwyNupTEzsgv0iNhAxQFGhV5yueEaK3A6pZlwahElRJvLv2VNIsZwqHjY HeNrNvJminwUoL47a7e8n9lhSJ60MTkMgJPX+L2x3CsAFqGzkD03cggwk4gGkj9QqjPI 8Fd13iKbnn6CEFTFfqHATv9+pdhQrylhr9B7IZpwgpumh/G1CfRHDGBO/flByLmaDWUk +CXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aXO456qaOP1M3JsJcts4UFcPXUKgBOMxL23ZB0rcMw4=; b=So4Mz50mnABZjuXoFFIyPSch8h5ivaNOsW1iSbjY3oPsPdb5UpM4+J9+8P9GUKacQv YSv6njlulUbum6+VmKSGg0gP2PCuZTqW4fdrieffDC7qUNLnyzLzV0X1TidWaUPsKCc9 8AktS9zqaW8cSiFOS9gJYHSZWK5KZXdreCE4cK978njBN+DfFnXYJuLN8DS3xpt5JFb2 E7nL+PWh7P+QGxi40vzghrQ22Ez9WcHrVr3jRjO60BlhzDC+OCs8Vfa3uWt4Dq+6VibV vHM+baFDf9MuQSodBKfGRfOS3OyPhid+uwUHJBMTas/fD/7t+UzVcr888oKgLXjjTwo/ ngsQ== X-Gm-Message-State: ANoB5pmAPW7qGPhBLG/CUH5Lhl2LjNJX/A1nlJEO/ovv84YX3EQQCIwl HqzzbAduzVzqLZJbjg2ZMoYjYA== X-Google-Smtp-Source: AA0mqf4kaujY5OpK6Ujxw29Abhy2Rzuycfz1mUU2y+kvw/dShqU187ciHHS5++sBtFImpPsluPd+/g== X-Received: by 2002:a02:c4d3:0:b0:363:d7b3:7d4 with SMTP id h19-20020a02c4d3000000b00363d7b307d4mr1242067jaj.166.1668187815869; Fri, 11 Nov 2022 09:30:15 -0800 (PST) Received: from [192.168.1.94] ([207.135.234.126]) by smtp.gmail.com with ESMTPSA id u18-20020a02b1d2000000b00375f143b0c2sm924332jah.8.2022.11.11.09.30.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Nov 2022 09:30:15 -0800 (PST) Message-ID: Date: Fri, 11 Nov 2022 10:30:13 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [RFC PATCH v3 00/14] mm/block: add bdi sysfs knobs Content-Language: en-US To: Stefan Roesch , kernel-team@fb.com, linux-block@vger.kernel.org, linux-mm@kvack.org Cc: clm@meta.com, willy@infradead.org, hch@infradead.org References: <20221024190603.3987969-1-shr@devkernel.io> From: Jens Axboe In-Reply-To: <20221024190603.3987969-1-shr@devkernel.io> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668187817; a=rsa-sha256; cv=none; b=8lJNQjG1BZOfqAabdhcWYG22nL9q2TRt9sEcSdaQhLuh0Nys96BsaAPsJcgiyWBwsRc4Ru yhP6u8K87fa/qcB2BkAj/augJq/ZOx1ulFxC598CMm60RPTcFkwz20xa3wg3iPFwEnidog Yh+4dN3IzzI3tyd2W2Atop4JB24QiK4= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=kernel-dk.20210112.gappssmtp.com header.s=20210112 header.b=mLUwO6Tq; dmarc=none; spf=pass (imf25.hostedemail.com: domain of axboe@kernel.dk designates 209.85.166.46 as permitted sender) smtp.mailfrom=axboe@kernel.dk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668187817; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=aXO456qaOP1M3JsJcts4UFcPXUKgBOMxL23ZB0rcMw4=; b=R18QFa6WyKLszZJrXlBq24RljPbZvg9TC7z8drRy37XFwgz363TtGPa/jRo8p1KEe6/IHH us82Y+NA+o2mVjkFEJ2i9/6Ki0NnSn6EJLx+/Ld6h+rDKlR63l08FUCnssasmzGC8OAfnQ ljm4ueY0HqLJuOi+BAwTW/G1pA7z3Hg= Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel-dk.20210112.gappssmtp.com header.s=20210112 header.b=mLUwO6Tq; dmarc=none; spf=pass (imf25.hostedemail.com: domain of axboe@kernel.dk designates 209.85.166.46 as permitted sender) smtp.mailfrom=axboe@kernel.dk X-Rspam-User: X-Stat-Signature: dfdwppenadbz1wupendob47gxzhwykhy X-Rspamd-Queue-Id: DB993A000B X-Rspamd-Server: rspam05 X-HE-Tag: 1668187816-452758 X-Bogosity: Ham, tests=bogofilter, spamicity=0.003319, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 10/24/22 1:05 PM, Stefan Roesch wrote: > At meta network block devices (nbd) are used to implement remote block > storage. In testing and during production it has been observed that > these network block devices can consume a huge portion of the dirty > writeback cache and writeback can take a considerable time. > > To be able to give stricter limits, I'm proposing the following changes: > > 1) introduce strictlimit knob > > Currently the max_ratio knob exists to limit the dirty_memory. However > this knob only applies once (dirty_ratio + dirty_background_ratio) / 2 > has been reached. > With the BDI_CAP_STRICTLIMIT flag, the max_ratio can be applied without > reaching that limit. This change exposes that knob. > > This knob can also be useful for NFS, fuse filesystems and USB devices. > > 2) Use part of 1000 internal calculation > > The max_ratio is based on percentage. With the current machine sizes > percentage values can be very high (1% of a 256GB main memory is already > 2.5GB). This change uses part of 1000 instead of percentages for the > internal calculations. > > 3) Introduce two new sysfs knobs: min_bytes and max_bytes. > > Currently all calculations are based on ratio, but for a user it often > more convenient to specify a limit in bytes. The new knobs will not > store bytes values, instead they will translate the byte value to a > corresponding ratio. As the internal values are now part of 1000, the > ratio is closer to the specified value. However the value should be more > seen as an approximation as it can fluctuate over time. Anyone have any concerns or input on this series? Would be nice to get it moving forward, as we do have a need for it at Meta. Outside of that, would be applicable for end-user use cases as well on the distro side. -- Jens Axboe