Messages in this thread | | | Subject | Re: [PATCH v2] mm: implement write-behind policy for sequential file writes | From | Konstantin Khlebnikov <> | Date | Mon, 23 Sep 2019 18:06:46 +0300 |
| |
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.
| |