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 E110CC433FE for ; Sat, 19 Nov 2022 00:19:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60DD48E0001; Fri, 18 Nov 2022 19:19:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BE116B0072; Fri, 18 Nov 2022 19:19:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 485638E0001; Fri, 18 Nov 2022 19:19:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 3A5206B0071 for ; Fri, 18 Nov 2022 19:19:47 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D3CE11A0780 for ; Sat, 19 Nov 2022 00:19:46 +0000 (UTC) X-FDA: 80148283572.13.BDEAE76 Received: from wnew2-smtp.messagingengine.com (wnew2-smtp.messagingengine.com [64.147.123.27]) by imf17.hostedemail.com (Postfix) with ESMTP id 52DAF40009 for ; Sat, 19 Nov 2022 00:19:46 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.west.internal (Postfix) with ESMTP id 8CC512B07345; Fri, 18 Nov 2022 19:19:44 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 18 Nov 2022 19:19:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=devkernel.io; h= cc:cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1668817184; x=1668820784; bh=prtbcy8N/1 rKugKj2vTvtItnBTqItgZYEcm/uusO8QU=; b=P9Qv0KCTBPHhYqGwupp0v55Ifi y+GwsnG8/2pzdM3tUjL2gWntdDHzJm3+hpwcBHIXwJMsNAoqDEuxtZ4cN0axfGw8 FugfI0cjnL8E5FB1j1+GZ6SlsUnoXsLMKBiVCI3/t/m8uetRdA//6BSua8ytbEMc J/WWq/OX3oWI28qlSKc0ocxwamDt+pbOSrNTIXzc4WxIUwHwNkFPPE+PZxJfFLYY kIFWZ1Der12RrVeRJZAudey7Beqd1IJLcoqfgagVPGqAEvxs07ZGCwByk16OnDFX /mA6/N4NVjzztJFBx9mYSngxmfyVeTDqjonlWPbeHhTa9BeUzmHB0zgUtBCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1668817184; x=1668820784; bh=prtbcy8N/1rKugKj2vTvtItnBTqI tgZYEcm/uusO8QU=; b=Wk5fp6KInm9ucluIm6eeyp9aCLMQEqlWNrF4/DZsbrOc PRpELuid6oDx+Z1+MlTQCscIsB8BUGbAN5uRcrd0d/1joQT0geLVMWZ/fL17YeBy ptcGTs6mNNF7eHd9LzoizcUWuVgzC4DOfllWXgtHh4DOjFXSkUYHqDoa0qkmHMkD da5IhobLDn0oayISGJ5L+6nio2RPTPb16r2KWP50xuEl+sZjQhPP//dDneJn1QzJ Dcf1cUNWM9uowvTkAY6rEl93WSpRvyuyy4Vg239DUKN4YfI2AK6morCmXpz9YF8G iodE569rxAZrskQphFM1YXjuIiw8EvM3xG0lRCF03A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrhedugddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfhgfhffvvefuffgjkfggtgesthdtre dttdertdenucfhrhhomhepufhtvghfrghnucftohgvshgthhcuoehshhhrseguvghvkhgv rhhnvghlrdhioheqnecuggftrfgrthhtvghrnhepveelgffghfehudeitdehjeevhedthf etvdfhledutedvgeeikeeggefgudeguedtnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepshhhrhesuggvvhhkvghrnhgvlhdrihho X-ME-Proxy: Feedback-ID: i84614614:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 18 Nov 2022 19:19:43 -0500 (EST) References: <20221024190603.3987969-1-shr@devkernel.io> <20221024190603.3987969-8-shr@devkernel.io> <20221116132916.564a26142c1f15c8553edb9f@linux-foundation.org> User-agent: mu4e 1.6.11; emacs 28.2.50 From: Stefan Roesch To: Andrew Morton Cc: kernel-team@fb.com, linux-block@vger.kernel.org, linux-mm@kvack.org, axboe@kernel.dk, clm@meta.com, willy@infradead.org, hch@infradead.org Subject: Re: [RFC PATCH v3 07/14] mm: add bdi_set_max_bytes() function. Date: Fri, 18 Nov 2022 16:16:27 -0800 In-reply-to: <20221116132916.564a26142c1f15c8553edb9f@linux-foundation.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668817186; a=rsa-sha256; cv=none; b=HRGRMn1uUrqPgHOI0Ab6ak+N1nmptQbH1OiVAV7FpQawuI6e3x5znMdwtn7Zy2fONKfX78 qyV680hSQ7gfZRp7iLz1jWTXpKSkETh1vjUwKLU3Q4gr2PoalLyKz7sLLWqm9xH51VqZcL YVfdKYGxDYH5VXs+oQjFIX4nT+ONF+4= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=devkernel.io header.s=fm2 header.b=P9Qv0KCT; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=Wk5fp6KI; spf=pass (imf17.hostedemail.com: domain of shr@devkernel.io designates 64.147.123.27 as permitted sender) smtp.mailfrom=shr@devkernel.io; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668817186; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=prtbcy8N/1rKugKj2vTvtItnBTqItgZYEcm/uusO8QU=; b=hsiir5JNsJoe970ql1P4TOgF7LGxL74+oM9FKJ2n9ZonNWi4aviDUmI7XLzkQIC57Bqf10 ATjgCycnoXWCsbAqto0KLDUuRXm92hRQm52KRG2mKBkZB62ESm3l9xCdP2o/sZPa1TrCON k7bqLSYFHM/PuPGD+rnlYrjeHRIDZao= X-Stat-Signature: in5917dqfjaaraetwas38zqoez1zry94 X-Rspamd-Queue-Id: 52DAF40009 X-Rspamd-Server: rspam01 X-Rspam-User: Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=devkernel.io header.s=fm2 header.b=P9Qv0KCT; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=Wk5fp6KI; spf=pass (imf17.hostedemail.com: domain of shr@devkernel.io designates 64.147.123.27 as permitted sender) smtp.mailfrom=shr@devkernel.io; dmarc=none X-HE-Tag: 1668817186-160679 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: Andrew Morton writes: > On Mon, 24 Oct 2022 12:05:56 -0700 Stefan Roesch wrote: > >> This introduces the bdi_set_max_bytes() function. The max_bytes function >> does not store the max_bytes value. Instead it converts the max_bytes >> value into the corresponding ratio value. >> >> ... >> >> --- a/include/linux/backing-dev.h >> +++ b/include/linux/backing-dev.h >> @@ -108,6 +108,7 @@ static inline unsigned long wb_stat_error(void) >> unsigned long long bdi_get_max_bytes(struct backing_dev_info *bdi); >> int bdi_set_min_ratio(struct backing_dev_info *bdi, unsigned int min_ratio); >> int bdi_set_max_ratio(struct backing_dev_info *bdi, unsigned int max_ratio); >> +int bdi_set_max_bytes(struct backing_dev_info *bdi, unsigned long long max_bytes); >> int bdi_set_strict_limit(struct backing_dev_info *bdi, unsigned int strict_limit); >> >> /* >> diff --git a/mm/page-writeback.c b/mm/page-writeback.c >> index 8b8936603783..21d7c1880ea8 100644 >> --- a/mm/page-writeback.c >> +++ b/mm/page-writeback.c >> @@ -13,6 +13,7 @@ >> */ >> >> #include >> +#include >> #include >> #include >> #include >> @@ -650,6 +651,28 @@ void wb_domain_exit(struct wb_domain *dom) >> */ >> static unsigned int bdi_min_ratio; >> >> +static int bdi_check_pages_limit(unsigned long pages) >> +{ >> + unsigned long max_dirty_pages = global_dirtyable_memory(); >> + >> + if (pages > max_dirty_pages / 2) >> + return -EINVAL; >> + >> + return 0; >> +} > > Some code comments are needed here. Explain what it does and why it > does it. The "/ 2" seems utterly arbitray - explain why this value was > chosen? Why is it better than "/ 3"? > > I changed the check to (pages > max_dirty_pages) > >> +static unsigned long bdi_ratio_from_pages(unsigned long pages) >> +{ >> + unsigned long background_thresh; >> + unsigned long dirty_thresh; >> + unsigned long ratio; >> + >> + global_dirty_limits(&background_thresh, &dirty_thresh); >> + ratio = div64_u64(pages * 100ULL * BDI_RATIO_SCALE, dirty_thresh); > > `unsigned long' is 32-bit on 32-bit machines, which makes this code a > bit odd. Should everything here be u64? The function global_dirty_limits() uses unsigned long pointers for its arguments. unsigned long looks like a better fit. Any thoughts?