From patchwork Tue Oct 11 01:00:30 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefan Roesch X-Patchwork-Id: 13003476 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 2429FC433FE for ; Tue, 11 Oct 2022 01:01:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 795DA6B0072; Mon, 10 Oct 2022 21:01:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 744056B0073; Mon, 10 Oct 2022 21:01:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 633936B0074; Mon, 10 Oct 2022 21:01:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 50ADE6B0072 for ; Mon, 10 Oct 2022 21:01:14 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 02F4D160F84 for ; Tue, 11 Oct 2022 01:01:13 +0000 (UTC) X-FDA: 80006864868.29.C79D021 Received: from 66-220-144-178.mail-mxout.facebook.com (66-220-144-178.mail-mxout.facebook.com [66.220.144.178]) by imf28.hostedemail.com (Postfix) with ESMTP id 8358BC0032 for ; Tue, 11 Oct 2022 01:01:12 +0000 (UTC) Received: by dev1180.prn1.facebook.com (Postfix, from userid 425415) id E1F2834BDD53; Mon, 10 Oct 2022 18:00:58 -0700 (PDT) From: Stefan Roesch To: kernel-team@fb.com, linux-block@vger.kernel.org, linux-mm@kvack.org Cc: shr@devkernel.io, axboe@kernel.dk, clm@meta.com Subject: [RFC PATCH v1 00/14] mm/block: add bdi sysfs knobs Date: Mon, 10 Oct 2022 18:00:30 -0700 Message-Id: <20221011010044.851537-1-shr@devkernel.io> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665450072; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references; bh=bXQ6BrqrvLg4QN+60N4Dmkq7ITNTjw9sgsBzcbU3oU8=; b=oHzz5xXx7wpSMlFWwXBcirsMY/0qre8ERdacc8QKi14NKrvP7dolydjb2mrk8Udkz2r+sz TwbiZxoO8SloAPpJ1I1s6N043kSe5QQJeao4CCQMZSZYL/RS/c1AuHvN/4VH7mkPuCBik6 ERbCrhocw+1oall4V38deMUH1+zvXaw= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; dmarc=none; spf=neutral (imf28.hostedemail.com: 66.220.144.178 is neither permitted nor denied by domain of shr@devkernel.io) smtp.mailfrom=shr@devkernel.io ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665450072; a=rsa-sha256; cv=none; b=Pk0IJXcjUblrrp0nwQltB0gMJH45PUtVWHjP1qnv3h8iwysLl09IN/KKzcY/4BpSKS+GNv CntLjXQJLCDiVUYgpt/ogeMWMVzL5sQvScD55POzhVYHfxSzXSGPXAfGAFefWeEXQF9I2Q GW4WCKGQ6dKlmHe7CeFfFrWKqL05Ea0= Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=none; spf=neutral (imf28.hostedemail.com: 66.220.144.178 is neither permitted nor denied by domain of shr@devkernel.io) smtp.mailfrom=shr@devkernel.io X-Stat-Signature: 4hymjbinezu5rz3t4odpwowgkoxk17r7 X-Rspamd-Queue-Id: 8358BC0032 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1665450072-212393 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 and writeback can take a considerable time. To give stricter limits, I'm proposing the following changes and new sysfs knobs: 1) 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) Part of 10000 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 10000 instead of percentages for the internal calculations. 3) Introduce two new 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 10000, the ratio is closer to the specified value. However the value should be more seen as an approximation as it can fluctuate over time. Stefan Roesch (14): mm: add bdi_set_strict_limit() function mm: Add new knob /sys/class/bdi//strict_limit mm: document new /sys/class/bdi//strict_limit knob mm: Use part per 10000 for bdi ratios. mm: add bdi_get_max_bytes() function mm: split off __bdi_set_max_ratio() function mm: add bdi_set_max_bytes() function. mm: Add new knob /sys/class/bdi//max_bytes mm: document new /sys/class/bdi//max_bytes knob mm: add bdi_get_min_bytes() function. mm: split off __bdi_set_min_ratio() function mm: add bdi_set_min_bytes() function mm: add new /sys/class/bdi//min_bytes knob mm: document new /sys/class/bdi//min_bytes knob Documentation/ABI/testing/sysfs-class-bdi | 40 +++++++ include/linux/backing-dev.h | 8 ++ mm/backing-dev.c | 93 +++++++++++++++- mm/page-writeback.c | 126 ++++++++++++++++++++-- 4 files changed, 253 insertions(+), 14 deletions(-) base-commit: e2302539dd4f1c62d96651c07ddb05aa2461d29c