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 X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64FEDC432C3 for ; Fri, 15 Nov 2019 03:32:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0237820709 for ; Fri, 15 Nov 2019 03:32:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0237820709 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 51ED56B0005; Thu, 14 Nov 2019 22:32:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CFFD6B0006; Thu, 14 Nov 2019 22:32:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E51B6B0007; Thu, 14 Nov 2019 22:32:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0057.hostedemail.com [216.40.44.57]) by kanga.kvack.org (Postfix) with ESMTP id 29C586B0005 for ; Thu, 14 Nov 2019 22:32:56 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id D0E882C98 for ; Fri, 15 Nov 2019 03:32:55 +0000 (UTC) X-FDA: 76157090310.22.spot20_70bd3c6dc4f3a X-HE-Tag: spot20_70bd3c6dc4f3a X-Filterd-Recvd-Size: 3732 Received: from mail3-166.sinamail.sina.com.cn (mail3-166.sinamail.sina.com.cn [202.108.3.166]) by imf14.hostedemail.com (Postfix) with SMTP for ; Fri, 15 Nov 2019 03:32:54 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([124.64.3.114]) by sina.com with ESMTP id 5DCE1C6100007DA9; Fri, 15 Nov 2019 11:32:51 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 96629554920840 From: Hillf Danton To: Jan Kara Cc: Hillf Danton , linux-mm , fsdev , Andrew Morton , linux-kernel , Fengguang Wu , Tejun Heo , Jan Kara , Johannes Weiner , Shakeel Butt , Minchan Kim , Mel Gorman Subject: Re: [RFC v2] writeback: add elastic bdi in cgwb bdp Date: Fri, 15 Nov 2019 11:32:40 +0800 Message-Id: <20191115033240.11236-1-hdanton@sina.com> In-Reply-To: <20191026104656.15176-1-hdanton@sina.com> References: <20191026104656.15176-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 14 Nov 2019 13:17:46 +0100 Jan Kara wrote: >=20 > On Sat 26-10-19 18:46:56, Hillf Danton wrote: > >=20 > > The elastic bdi is the mirror bdi of spinning disks, SSD, USB and > > other storage devices/instruments on market. The performance of > > ebdi goes up and down as the pattern of IO dispatched changes, as > > approximately estimated as below. > >=20 > > P =3D j(..., IO pattern); > >=20 > > In ebdi's view, the bandwidth currently measured in balancing dirty > > pages has close relation to its performance because the former is a > > part of the latter. > >=20 > > B =3D y(P); > >=20 > > The functions above suggest there may be a layer violation if it > > could be better measured somewhere below fs. > >=20 > > It is measured however to the extent that makes every judge happy, > > and is playing a role in dispatching IO with the IO pattern entirely > > ignored that is volatile in nature. > >=20 > > And it helps to throttle the dirty speed, with the figure ignored > > that DRAM in general is x10 faster than ebdi. If B is half of P for > > instance, then it is near 5% of dirty speed, just 2 points from the > > figure in the snippet below. > >=20 > > /* > > * If ratelimit_pages is too high then we can get into dirty-data ove= rload > > * if a large number of processes all perform writes at the same time= . > > * If it is too low then SMP machines will call the (expensive) > > * get_writeback_state too often. > > * > > * Here we set ratelimit_pages to a level which ensures that when all= CPUs are > > * dirtying in parallel, we cannot go more than 3% (1/32) over the di= rty memory > > * thresholds. > > */ > >=20 > > To prevent dirty speed from running away from laundry speed, ebdi > > suggests the walk-dog method to put in bdp as a leash seems to > > churn less in IO pattern. > >=20 > > V2 is based on next-20191025. >=20 > Honestly, the changelog is still pretty incomprehensible as Andrew alre= ady > mentioned. Also I completely miss there, what are the benefits of this = work > compared to what we currently have. >=20 Hey Jan In the room which has been somewhere between 3% and 5% for bdp since 143dfe8611a6 ("writeback: IO-less balance_dirty_pages()") a bdp is proposed with target of surviving tests like LTP without regressions introduced, so overall the concerned benefit is that bdp is becoming more diverse if the diversity under linux/fs is good for the 99%. Hillf