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,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 219B4C432C1 for ; Tue, 24 Sep 2019 07:39:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E016320640 for ; Tue, 24 Sep 2019 07:39:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E016320640 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fromorbit.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 790596B0006; Tue, 24 Sep 2019 03:39:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 71A296B0007; Tue, 24 Sep 2019 03:39:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B9516B0008; Tue, 24 Sep 2019 03:39:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0252.hostedemail.com [216.40.44.252]) by kanga.kvack.org (Postfix) with ESMTP id 342226B0006 for ; Tue, 24 Sep 2019 03:39:51 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 988DC181AC9B4 for ; Tue, 24 Sep 2019 07:39:50 +0000 (UTC) X-FDA: 75969014940.02.chess51_72fb928b8a803 X-HE-Tag: chess51_72fb928b8a803 X-Filterd-Recvd-Size: 3253 Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Sep 2019 07:39:50 +0000 (UTC) Received: from dread.disaster.area (pa49-181-226-196.pa.nsw.optusnet.com.au [49.181.226.196]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id A37D343D63A; Tue, 24 Sep 2019 17:39:41 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.2) (envelope-from ) id 1iCfQC-0000C1-Fo; Tue, 24 Sep 2019 17:39:40 +1000 Date: Tue, 24 Sep 2019 17:39:40 +1000 From: Dave Chinner To: Konstantin Khlebnikov Cc: Tejun Heo , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jens Axboe , Michal Hocko , Mel Gorman , Johannes Weiner , Linus Torvalds Subject: Re: [PATCH v2] mm: implement write-behind policy for sequential file writes Message-ID: <20190924073940.GM6636@dread.disaster.area> References: <156896493723.4334.13340481207144634918.stgit@buzz> <875f3b55-4fe1-e2c3-5bee-ca79e4668e72@yandex-team.ru> <20190923145242.GF2233839@devbig004.ftw2.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=P6RKvmIu c=1 sm=1 tr=0 a=dRuLqZ1tmBNts2YiI0zFQg==:117 a=dRuLqZ1tmBNts2YiI0zFQg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=J70Eh1EUuV4A:10 a=7-415B0cAAAA:8 a=wSS0DcxVZBN270Py4OYA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 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, Sep 23, 2019 at 06:06:46PM +0300, Konstantin Khlebnikov wrote: > On 23/09/2019 17.52, Tejun Heo wrote: > > Hello, Konstantin. > > > > On Fri, Sep 20, 2019 at 10:39:33AM +0300, Konstantin Khlebnikov wrote: > > > With vm.dirty_write_behind 1 or 2 files are written even faster and > > > > Is the faster speed reproducible? I don't quite understand why this > > would be. > > Writing to disk simply starts earlier. Stupid question: how is this any different to simply winding down our dirty writeback and throttling thresholds like so: # echo $((100 * 1000 * 1000)) > /proc/sys/vm/dirty_background_bytes to start background writeback when there's 100MB of dirty pages in memory, and then: # echo $((200 * 1000 * 1000)) > /proc/sys/vm/dirty_bytes So that writers are directly throttled at 200MB of dirty pages in memory? This effectively gives us global writebehind behaviour with a 100-200MB cache write burst for initial writes. ANd, really such strict writebehind behaviour is going to cause all sorts of unintended problesm with filesystems because there will be adverse interactions with delayed allocation. We need a substantial amount of dirty data to be cached for writeback for fragmentation minimisation algorithms to be able to do their job.... Cheers, Dave. -- Dave Chinner david@fromorbit.com