Re: [PATCH v2] mm: implement write-behind policy for sequential file writes
From: Konstantin Khlebnikov
Date: Mon Sep 23 2019 - 11:06:53 EST
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.
during copying amount of dirty memory always stays around at 16MiB.
The following is the test part of a slightly modified version of your
test script which should run fine on any modern systems.
for mode in 0 1; do
if [ $mode == 0 ]; then
prefix=''
else
prefix='systemd-run --user --scope -p MemoryMax=64M'
fi
echo COPY
time $prefix cp -r dummy copy
grep Dirty /proc/meminfo
echo SYNC
time sync
rm -fr copy
done
and the result looks like the following.
$ ./test-writebehind.sh
SIZE
3.3G dummy
COPY
real 0m2.859s
user 0m0.015s
sys 0m2.843s
Dirty: 3416780 kB
SYNC
real 0m34.008s
user 0m0.000s
sys 0m0.008s
COPY
Running scope as unit: run-r69dca5326a9a435d80e036435ff9e1da.scope
real 0m32.267s
user 0m0.032s
sys 0m4.186s
Dirty: 14304 kB
SYNC
real 0m1.783s
user 0m0.000s
sys 0m0.006s
This is how we are solving the massive dirtier problem. It's easy,
works pretty well and can easily be tailored to the specific
requirements.
Generic write-behind would definitely have other benefits and also a
bunch of regression possibilities. I'm not trying to say that
write-behind isn't a good idea but it'd be useful to consider that a
good portion of the benefits can already be obtained fairly easily.
I'm afraid this could end badly if each simple task like file copying
will require own systemd job and container with manual tuning.