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.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 71562C3A5A2 for ; Fri, 20 Sep 2019 23:05:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0A6802073F for ; Fri, 20 Sep 2019 23:05:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="Cc5gWnHv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A6802073F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 69F046B0005; Fri, 20 Sep 2019 19:05:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6270E6B0006; Fri, 20 Sep 2019 19:05:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C6D56B0007; Fri, 20 Sep 2019 19:05:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0225.hostedemail.com [216.40.44.225]) by kanga.kvack.org (Postfix) with ESMTP id 252D56B0005 for ; Fri, 20 Sep 2019 19:05:39 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id A75A5824CA3B for ; Fri, 20 Sep 2019 23:05:38 +0000 (UTC) X-FDA: 75956832756.22.guide77_6b6c6e91e8e1d X-HE-Tag: guide77_6b6c6e91e8e1d X-Filterd-Recvd-Size: 4655 Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Fri, 20 Sep 2019 23:05:38 +0000 (UTC) Received: by mail-lj1-f193.google.com with SMTP id m7so8578519lji.2 for ; Fri, 20 Sep 2019 16:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mtHJRljpIthtHGh3XxE5kG38evjyZkXXa2KwhkF3cfE=; b=Cc5gWnHvSFkt/XOMA27VwmYwG7DVJmBzs0dIyEV6yq14mog53/7iNdQvPU8DH7UYCO WARG7/ZwIOBICzkQ8IQmexLNL7Ke5E6YBstlJKL71nq+d4fqB4s2qSAcsuYAbWAYHSRu k6yu+jXAPxOkH/L5OLNGuUB3Vt3R3U+Wxs+NE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mtHJRljpIthtHGh3XxE5kG38evjyZkXXa2KwhkF3cfE=; b=jrY69/tG5s9+bekAMu8LhxmY6j1WSgplY7I0OfaiwI9+qQ2zmD2prAL3mdePrbsWG/ smeg89uKih4cRKZb8hxYgnpqLeqFQlod0TJ0+TolRAFGEfGhVsToAPdPTve9GjuyOqkO 9SBU/HThCJy92BuBd95yZGn9KQLT080YuCNvFWf1OvTv+mW9PbAQXW7nlOdi39Vrc7mA 0CsRujql+/GNe4KKBgpfBqqsggVtaixNCY10hFaXpZPhutP1eUWKw9Uh8ZB7XtWHvsnu 7+4yYEw5Jm8D6ub4xzvxqevm5io/Ajg5OUSDStRWqktDM18JjhcEt0I5zKcK1HDwKAL1 X1gQ== X-Gm-Message-State: APjAAAXva/kRpGJGk21TbKDI0apae+IHPJV7SqpxqxTP+agZEMWb/pu9 dTy8L3WdpS9lqb8K4om3XtHvP7PwkfY= X-Google-Smtp-Source: APXvYqwJlXgePoTAiSZyg4yZmc4ySMUSkpeliv+vPICTzqICZN7qo2Sj+CjYZl6WrDImeHrB3a+HWQ== X-Received: by 2002:a2e:91d0:: with SMTP id u16mr10503572ljg.164.1569020735788; Fri, 20 Sep 2019 16:05:35 -0700 (PDT) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com. [209.85.208.181]) by smtp.gmail.com with ESMTPSA id k8sm830975ljg.9.2019.09.20.16.05.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Sep 2019 16:05:33 -0700 (PDT) Received: by mail-lj1-f181.google.com with SMTP id y3so7166006ljj.6 for ; Fri, 20 Sep 2019 16:05:33 -0700 (PDT) X-Received: by 2002:a2e:96d3:: with SMTP id d19mr1246398ljj.165.1569020733395; Fri, 20 Sep 2019 16:05:33 -0700 (PDT) MIME-Version: 1.0 References: <156896493723.4334.13340481207144634918.stgit@buzz> In-Reply-To: <156896493723.4334.13340481207144634918.stgit@buzz> From: Linus Torvalds Date: Fri, 20 Sep 2019 16:05:17 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] mm: implement write-behind policy for sequential file writes To: Konstantin Khlebnikov Cc: linux-fsdevel , Linux-MM , Linux Kernel Mailing List , Jens Axboe , Michal Hocko , Dave Chinner , Mel Gorman , Johannes Weiner , Tejun Heo Content-Type: text/plain; charset="UTF-8" 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, Sep 20, 2019 at 12:35 AM Konstantin Khlebnikov wrote: > > This patch implements write-behind policy which tracks sequential writes > and starts background writeback when file have enough dirty pages. Apart from a spelling error ("contigious"), my only reaction is that I've wanted this for the multi-file writes, not just for single big files. Yes, single big files may be a simpler and perhaps the "10% effort for 90% of the gain", and thus the right thing to do, but I do wonder if you've looked at simply extending it to cover multiple files when people copy a whole directory (or unpack a tar-file, or similar). Now, I hear you say "those are so small these days that it doesn't matter". And maybe you're right. But partiocularly for slow media, triggering good streaming write behavior has been a problem in the past. So I'm wondering whether the "writebehind" state should perhaps be considered be a process state, rather than "struct file" state, and also start triggering for writing smaller files. Maybe this was already discussed and people decided that the big-file case was so much easier that it wasn't worth worrying about writebehind for multiple files. Linus