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 F05C2C4332F for ; Wed, 16 Nov 2022 21:29:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 77E036B0078; Wed, 16 Nov 2022 16:29:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 72E588E0002; Wed, 16 Nov 2022 16:29:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CF0F8E0001; Wed, 16 Nov 2022 16:29:21 -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 4E50D6B0078 for ; Wed, 16 Nov 2022 16:29:21 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0DCCB1C60B6 for ; Wed, 16 Nov 2022 21:29:20 +0000 (UTC) X-FDA: 80140596522.17.66C34ED Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf29.hostedemail.com (Postfix) with ESMTP id 6DE4C120013 for ; Wed, 16 Nov 2022 21:29:20 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 09EAFB81D80; Wed, 16 Nov 2022 21:29:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6BBEFC433D6; Wed, 16 Nov 2022 21:29:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1668634157; bh=djYHaWyhxCzztBQzBwasQx+gb86ZzrqajkqDb8YKU80=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=LAo1yjsrG0zroAlo8F7QbbvejLzWRMmfW6kWVO5fNKKjSUdmZ06EvfMydP62jh0Ok VVX69eSLVE9jdU94cGOU/vEjht8kCLeWuDfsjzO7pN4pwLZAS7K7PtvGx9fZuNHQnL OGnBQ/cmgN/NwAHiSd9eKWNzVI2cVWt8wDW2cJKE= Date: Wed, 16 Nov 2022 13:29:16 -0800 From: Andrew Morton To: Stefan Roesch 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. Message-Id: <20221116132916.564a26142c1f15c8553edb9f@linux-foundation.org> In-Reply-To: <20221024190603.3987969-8-shr@devkernel.io> References: <20221024190603.3987969-1-shr@devkernel.io> <20221024190603.3987969-8-shr@devkernel.io> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668634160; a=rsa-sha256; cv=none; b=yWm2cfGS03YsyjYmKGHIfc7ROcUrAgUiO4dp2IoF3Qoaa3UdLAZJ8/BytHZUvISB20UrTE 2oz76ex/mEAP9HpjUXKDqpYaBeqA/DTgSomgQC0YYdt3rnf52GfBMXxGsHrRek9IlGXHJv ltunHo/lbjc4H9t8fLFBoQO21TSjBXI= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=LAo1yjsr; spf=pass (imf29.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668634160; 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=nEhcCyBMUHKOEij2SCgk9mL9xCLEK4rqgHVTF7WgOl0=; b=EXldc93JFRcef0dxX3Gc7ATtUrbvAvQro5XnUTKgE4XmlFRGkyuPHEemZV0Dkjf1C4m19x 6VvMXY1ztzlWi5735TMl8ZDI3UIMQvBQ/O1iIJ6Fale8NzyQ9uu5Wa3VWaIvl4/VcPwWZY tyq86cxws3lvQ21hTN3vNivBwz61tk8= X-Stat-Signature: errmeweuiwggpomgkq8y9ih4psyckeza X-Rspamd-Queue-Id: 6DE4C120013 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=LAo1yjsr; spf=pass (imf29.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1668634160-694930 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: 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"? > +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?