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.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 E3F04C4320D for ; Tue, 24 Sep 2019 09:00:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 99EDB214D9 for ; Tue, 24 Sep 2019 09:00:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=yandex-team.ru header.i=@yandex-team.ru header.b="hMBfVPo+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 99EDB214D9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=yandex-team.ru Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 382BE6B0005; Tue, 24 Sep 2019 05:00:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 333A06B0006; Tue, 24 Sep 2019 05:00:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 248966B0007; Tue, 24 Sep 2019 05:00:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0169.hostedemail.com [216.40.44.169]) by kanga.kvack.org (Postfix) with ESMTP id 016D06B0005 for ; Tue, 24 Sep 2019 05:00:23 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 97EC7181AC9AE for ; Tue, 24 Sep 2019 09:00:23 +0000 (UTC) X-FDA: 75969217926.06.box77_5a95010ceeb1c X-HE-Tag: box77_5a95010ceeb1c X-Filterd-Recvd-Size: 4524 Received: from forwardcorp1j.mail.yandex.net (forwardcorp1j.mail.yandex.net [5.45.199.163]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Sep 2019 09:00:22 +0000 (UTC) Received: from mxbackcorp1o.mail.yandex.net (mxbackcorp1o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::301]) by forwardcorp1j.mail.yandex.net (Yandex) with ESMTP id CD2CF2E1318; Tue, 24 Sep 2019 12:00:18 +0300 (MSK) Received: from sas2-62907d92d1d8.qloud-c.yandex.net (sas2-62907d92d1d8.qloud-c.yandex.net [2a02:6b8:c08:b895:0:640:6290:7d92]) by mxbackcorp1o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id kRCekL2Kks-0HLSQhvt; Tue, 24 Sep 2019 12:00:18 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1569315618; bh=XWcumQ6LEVVd+nqcjbDRZkT8POGeVs8ZdFkLhiZbTSI=; h=In-Reply-To:Message-ID:From:Date:References:To:Subject:Cc; b=hMBfVPo+LVt6lT9a9TMgtbPb13atRa5vC0BbTPaJPzZQEvlN5VYzXH8xP62mYkBVm 3bkgWYVMffqI4hoMwA+tbFvjJyemGfPUDhrdVumO9hCFnEtAaeRf8GYdTe59TMEC15 0u/G5ED+L8iRCekkV4E5ujHsjZrWLjLibN01StJo= Authentication-Results: mxbackcorp1o.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Received: from dynamic-red.dhcp.yndx.net (dynamic-red.dhcp.yndx.net [2a02:6b8:0:40c:3d4d:a9cb:ef29:4bb1]) by sas2-62907d92d1d8.qloud-c.yandex.net (nwsmtp/Yandex) with ESMTPSA id XQYXi9VcIO-0HH8Sl58; Tue, 24 Sep 2019 12:00:17 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) Subject: Re: [PATCH v2] mm: implement write-behind policy for sequential file writes To: Dave Chinner 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 References: <156896493723.4334.13340481207144634918.stgit@buzz> <875f3b55-4fe1-e2c3-5bee-ca79e4668e72@yandex-team.ru> <20190923145242.GF2233839@devbig004.ftw2.facebook.com> <20190924073940.GM6636@dread.disaster.area> From: Konstantin Khlebnikov Message-ID: Date: Tue, 24 Sep 2019 12:00:17 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190924073940.GM6636@dread.disaster.area> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 7bit 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 24/09/2019 10.39, Dave Chinner wrote: > 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. Global limits affect all dirty pages including memory-mapped and randomly touched. Write-behind aims only into sequential streams. > > 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.... I think most sequentially written files never change after close. Except of knowing final size of huge files (>16Mb in my patch) there should be no difference for delayed allocation. Probably write behind could provide hint about streaming pattern: pass something like "MSG_MORE" into writeback call. > > Cheers, > > Dave. >