From: Dave Chinner <david@fromorbit.com>
To: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: Tejun Heo <tj@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
Michal Hocko <mhocko@suse.com>, Mel Gorman <mgorman@suse.de>,
Johannes Weiner <hannes@cmpxchg.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v2] mm: implement write-behind policy for sequential file writes
Date: Tue, 24 Sep 2019 17:39:40 +1000 [thread overview]
Message-ID: <20190924073940.GM6636@dread.disaster.area> (raw)
In-Reply-To: <ed5d930c-88c6-c8e4-4a6c-529701caa993@yandex-team.ru>
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
next prev parent reply other threads:[~2019-09-24 7:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-20 7:35 [PATCH v2] mm: implement write-behind policy for sequential file writes Konstantin Khlebnikov
2019-09-20 7:39 ` Konstantin Khlebnikov
2019-09-23 14:52 ` Tejun Heo
2019-09-23 15:06 ` Konstantin Khlebnikov
2019-09-23 15:19 ` Tejun Heo
2019-09-24 7:39 ` Dave Chinner [this message]
2019-09-24 9:00 ` Konstantin Khlebnikov
2019-09-25 7:18 ` Dave Chinner
2019-09-25 8:15 ` Konstantin Khlebnikov
2019-09-25 23:25 ` Dave Chinner
2019-09-25 12:54 ` Theodore Y. Ts'o
2019-09-24 19:08 ` Linus Torvalds
2019-09-25 8:00 ` Dave Chinner
2019-09-20 23:05 ` Linus Torvalds
2019-09-20 23:10 ` Linus Torvalds
2019-09-23 15:36 ` Jens Axboe
2019-09-23 16:05 ` Konstantin Khlebnikov
2019-09-24 9:29 ` Konstantin Khlebnikov
2019-09-22 7:47 ` kbuild test robot
2019-09-23 0:36 ` [mm] e0e7df8d5b: will-it-scale.per_process_ops -7.3% regression kernel test robot
2019-09-23 19:11 ` Konstantin Khlebnikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190924073940.GM6636@dread.disaster.area \
--to=david@fromorbit.com \
--cc=axboe@kernel.dk \
--cc=hannes@cmpxchg.org \
--cc=khlebnikov@yandex-team.ru \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).