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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 DA3E1C43141 for ; Fri, 15 Nov 2019 09:53:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9FC832072D for ; Fri, 15 Nov 2019 09:53:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9FC832072D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1E0946B0007; Fri, 15 Nov 2019 04:53:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 191F46B0008; Fri, 15 Nov 2019 04:53:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A75D6B000A; Fri, 15 Nov 2019 04:53:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0130.hostedemail.com [216.40.44.130]) by kanga.kvack.org (Postfix) with ESMTP id E73086B0007 for ; Fri, 15 Nov 2019 04:53:03 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 8F87C82499B9 for ; Fri, 15 Nov 2019 09:53:03 +0000 (UTC) X-FDA: 76158048246.26.doll93_54debdf4a7c00 X-HE-Tag: doll93_54debdf4a7c00 X-Filterd-Recvd-Size: 4162 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Fri, 15 Nov 2019 09:53:03 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 3AD6BB18D; Fri, 15 Nov 2019 09:53:01 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 62F3C1E3BEA; Fri, 15 Nov 2019 10:53:00 +0100 (CET) Date: Fri, 15 Nov 2019 10:53:00 +0100 From: Jan Kara To: Hillf Danton Cc: Jan Kara , 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 Message-ID: <20191115095300.GB9043@quack2.suse.cz> References: <20191026104656.15176-1-hdanton@sina.com> <20191115033240.11236-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191115033240.11236-1-hdanton@sina.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Fri 15-11-19 11:32:40, Hillf Danton wrote: > > On Thu, 14 Nov 2019 13:17:46 +0100 Jan Kara wrote: > > > > On Sat 26-10-19 18:46:56, Hillf Danton wrote: > > > > > > 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. > > > > > > P = j(..., IO pattern); > > > > > > 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. > > > > > > B = y(P); > > > > > > The functions above suggest there may be a layer violation if it > > > could be better measured somewhere below fs. > > > > > > 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. > > > > > > 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. > > > > > > /* > > > * If ratelimit_pages is too high then we can get into dirty-data overload > > > * 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 dirty memory > > > * thresholds. > > > */ > > > > > > 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. > > > > > > V2 is based on next-20191025. > > > > Honestly, the changelog is still pretty incomprehensible as Andrew already > > mentioned. Also I completely miss there, what are the benefits of this work > > compared to what we currently have. > > > 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%. What do you mean by "balance_dirty_pages() is becoming more diverse"? Honza -- Jan Kara SUSE Labs, CR