Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1715245ybn; Thu, 26 Sep 2019 00:44:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqyn6PxZKfk+lBwinxebxkw4B5Ka4yCoSB1G3LZxNrZYzOzSf/YkJlfEW0q3OYQmka8S9IMw X-Received: by 2002:a05:6402:281:: with SMTP id l1mr2158337edv.40.1569483896404; Thu, 26 Sep 2019 00:44:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569483896; cv=none; d=google.com; s=arc-20160816; b=XtOZ9LzcIB/4MI0txtf7tph2kcuLOLCbYp4rM1PF55M2+1xU232Cdpc4V6SyCtOt8P YJhrJQ9s/WBUrs5rhKMoB7xZBn00GlZzK4Jv9RbP5GU1qH3EbGlO3G+exu2whlaoPhjq 0RQcHdC2MouoncxHTEy5pm8EHjusJWbxnTlqTDYDMI5V/C6t/GGSY+k4VeWj5cVuBpCW zSbqxoU2HrNVKjNWApcngexnZ08/nIIRAwAl9HjLw6T+1yAHuNThqkVAEPtSwbNkkUtQ Jc9cveZVU5kXvaN8TP7MwouFDqOtuv86gt5ZKzrDPGX+BaDgCkjSKRNJ/1BBSNqWqmRq ZMVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=XWcumQ6LEVVd+nqcjbDRZkT8POGeVs8ZdFkLhiZbTSI=; b=pw2ftUS/HwlGwc1cXmPlty2I9MdJCF3t/b4HFqHwBZeC8BXhTyT2Kx7H7P8ANh4Eve /i1RivGybVGGF3av5AbnLaA89kOcYpw7HqKXRWju+h0Li5f8iwbFEvexsiltXLk3e/9Q j+lANsN2akp6wyVtXIOE5XollFKlT/C6VwMQngSm1ORY8231zVEvFyCUEVciZ4gyBkhS v/sgpPo3rXN3CHuYZcN4AJPdjw4RH2CRCMEhDark8/pgH+5r8HJ6r3f+pBMKlLRAOznt opSE6NVMd6ZXcbRjyYd5tCPkv3d0hBh6Bpb+9vdbmwYtRkW27TY3fJyqCPchhuv83r/h JS3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@yandex-team.ru header.s=default header.b=hMBfVPo+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yandex-team.ru Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o32si844165edc.306.2019.09.26.00.44.33; Thu, 26 Sep 2019 00:44:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@yandex-team.ru header.s=default header.b=hMBfVPo+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yandex-team.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394843AbfIXJAX (ORCPT + 99 others); Tue, 24 Sep 2019 05:00:23 -0400 Received: from forwardcorp1j.mail.yandex.net ([5.45.199.163]:41214 "EHLO forwardcorp1j.mail.yandex.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729588AbfIXJAW (ORCPT ); Tue, 24 Sep 2019 05:00:22 -0400 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. >