Messages in this thread | | | Subject | Re: [PATCH v2] mm: implement write-behind policy for sequential file writes | From | Konstantin Khlebnikov <> | Date | Tue, 24 Sep 2019 12:00:17 +0300 |
| |
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. >
| |