From patchwork Mon Oct 17 18:13:23 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefan Roesch X-Patchwork-Id: 13009223 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 3CAD6C433FE for ; Mon, 17 Oct 2022 18:14:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9DE4B6B0074; Mon, 17 Oct 2022 14:14:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 98E246B0075; Mon, 17 Oct 2022 14:14:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87DFA6B0078; Mon, 17 Oct 2022 14:14:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 74D846B0074 for ; Mon, 17 Oct 2022 14:14:11 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 446E01204F5 for ; Mon, 17 Oct 2022 18:14:11 +0000 (UTC) X-FDA: 80031240702.17.F42A8A6 Received: from 66-220-144-178.mail-mxout.facebook.com (66-220-144-178.mail-mxout.facebook.com [66.220.144.178]) by imf13.hostedemail.com (Postfix) with ESMTP id D737A2003C for ; Mon, 17 Oct 2022 18:14:09 +0000 (UTC) Received: by dev1180.prn1.facebook.com (Postfix, from userid 425415) id 0E33E39C99B2; Mon, 17 Oct 2022 11:13:56 -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, willy@infradead.org, hch@infradead.org Subject: [RFC PATCH v2 00/14] mm/block: add bdi sysfs knobs Date: Mon, 17 Oct 2022 11:13:23 -0700 Message-Id: <20221017181337.3884657-1-shr@devkernel.io> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666030450; a=rsa-sha256; cv=none; b=a1o0PE0BWJs7xmNiR9OMCkM+l9SgYjInzSTjiRhJwIRksL567D1e9fE9vynP7XyPSzy91e exV+q0gRDiyrKDPtMbZwJFWaDjgbKes62uwT9I6mE7usgU2lhph5/eeOLl0mXADA0IPcvU xwCVXXDP+k4ppqPwk4ueOJuKjwneD4k= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=none; spf=neutral (imf13.hostedemail.com: 66.220.144.178 is neither permitted nor denied by domain of shr@devkernel.io) smtp.mailfrom=shr@devkernel.io ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666030450; 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=WVhFhUjbq9LV2XDZR0upnR2FPKE4aVZvl+gCCHOcNeE=; b=JYgjlT+FxKod7bXUku+Y1Lgz7MZyfCNWyqEd1DEijbij/Br6FrO4bt8w58sOdE378psAQB 1lw2YXPgaWeETfrrALeV8JP7SbroGPTsHL9XQuNL1T4eFMMr6LLQYmYhNgdk8NMqBu3M6W jGjq924ey8mKko4y1vyXeF15u7dbX5E= X-Rspamd-Server: rspam05 X-Rspam-User: X-Rspamd-Queue-Id: D737A2003C Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=none; spf=neutral (imf13.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: og83nxngyu5oa1cipozmwoxxap8giaii X-HE-Tag: 1666030449-249265 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 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. Changes: - Refreshed to 6.1-rc1 - Use part of 1000, instead of part of 10000 - Reformat cover letter Stefan Roesch (14): mm: add bdi_set_strict_limit() function mm: add knob /sys/class/bdi//strict_limit mm: document /sys/class/bdi//strict_limit knob mm: use part per 1000 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 knob /sys/class/bdi//max_bytes mm: document /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 /sys/class/bdi//min_bytes knob mm: document /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: 9abf2313adc1ca1b6180c508c25f22f9395cc780