On 2.11.18 г. 9:13 ч., ethanlien wrote:
> David Sterba 於 2018-11-02 02:02 寫到:
>> On Thu, Nov 01, 2018 at 02:49:03PM +0800, Ethan Lien wrote:
>>> Snapshot is expected to be fast. But if there are writers steadily
>>> create dirty pages in our subvolume, the snapshot may take a very long
>>> time to complete. To fix the problem, we use tagged writepage for
>>> snapshot
>>> flusher as we do in the generic write_cache_pages(), so we can ommit
>>> pages
>>> dirtied after the snapshot command.
>>>
>>> We do a simple snapshot speed test on a Intel D-1531 box:
>>>
>>> fio --ioengine=libaio --iodepth=32 --bs=4k --rw=write --size=64G
>>> --direct=0 --thread=1 --numjobs=1 --time_based --runtime=120
>>> --filename=/mnt/sub/testfile --name=job1 --group_reporting & sleep 5;
>>> time btrfs sub snap -r /mnt/sub /mnt/snap; killall fio
>>>
>>> original: 1m58sec
>>> patched: 6.54sec
>>>
>>> This is the best case for this patch since for a sequential write case,
>>> we omit nearly all pages dirtied after the snapshot command.
>>>
>>> For a multi writers, random write test:
>>>
>>> fio --ioengine=libaio --iodepth=32 --bs=4k --rw=randwrite --size=64G
>>> --direct=0 --thread=1 --numjobs=4 --time_based --runtime=120
>>> --filename=/mnt/sub/testfile --name=job1 --group_reporting & sleep 5;
>>> time btrfs sub snap -r /mnt/sub /mnt/snap; killall fio
>>>
>>> original: 15.83sec
>>> patched: 10.35sec
>>>
>>> The improvement is less compared with the sequential write case, since
>>> we omit only half of the pages dirtied after snapshot command.
>>>
>>> Signed-off-by: Ethan Lien <ethanl...@synology.com>
>>
>> This looks nice, thanks. I agree with the The suggestions from Nikolay,
>> please update and resend.
>>
>> I was bit curious about the 'livelock', what you describe does not seem
>> to be one. System under heavy IO can make the snapshot dead slow but can
>> recover from that once the IO stops.>
> I'm not sure if this is indeed the case of 'livelock'. I learn the term
> from commit:
> f446daaea9d4a420d, "mm: implement writeback livelock avoidance using
> page tagging".
> If this is not the case, I can use another term.
It's really bad to use terms you don't fully comprehend because that way
you can, inadvertently, mislead people who don't necessarily have the
same context as you do. A brief description of what livelock can be
found here:
https://stackoverflow.com/questions/6155951/whats-the-difference-between-deadlock-and-livelock
In the context of wb livelock could occur since you have 2 processes - 1
producer (dirtying pages) and the other one consumer (writeback). So a
livelock will be when both are doing useful work yet the system doesn't
make forward progress ( in this case there is a risk of the snapshot
never being created since we will never finish doing the writeback for
constantly dirtied pages).
David, indeed what Ethan fixes and what Jan fixed in f446daaea9d4a420d
are the same class of issues. And livelock in this context really
depends on one's definition of how long a
no-forward-progress-but-useful-work-being-done situation persisting.
>
>> Regarding the sync semantics, there's AFAIK no change to the current
>> state where the sync is done before snapshot but without further other
>> guarantees. From that point I think it's safe to select only subset of
>> pages and make things faster.
>>
>> As the requested changes are not functional I'll add the patch to
>> for-next for testing.
>
>
