[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 7/7] introduce simple linear scan rate limiting mechanism
From: |
Peter Xu |
Subject: |
Re: [PATCH v3 7/7] introduce simple linear scan rate limiting mechanism |
Date: |
Thu, 19 Nov 2020 15:02:50 -0500 |
On Thu, Nov 19, 2020 at 03:59:40PM +0300, Andrey Gruzdev wrote:
> Since reading UFFD events and saving paged data are performed
> from the same thread, write fault latencies are sensitive to
> migration stream stalls. Limiting total page saving rate is a
> method to reduce amount of noticiable fault resolution latencies.
>
> Migration bandwidth limiting is achieved via noticing cases of
> out-of-threshold write fault latencies and temporarily disabling
> (strictly speaking, severely throttling) saving non-faulting pages.
Just curious: have you measured aver/max latency of wr-protected page requests,
or better, even its distribution?
I believe it should also be relevant to where the snapshot is stored, say, the
backend disk of your tests. Is that a file on some fs?
I would expect the latency should be still good if e.g. the throughput of the
backend file system is decent even without a patch like this, but I might have
missed something..
In all cases, it would be very nice if this patch can have the histogram or
aver or max latency measured and compared before/after this patch applied.
Thanks,
--
Peter Xu
- Re: [PATCH v3 3/7] support UFFD write fault processing in ram_save_iterate(), (continued)
[PATCH v3 4/7] implementation of write-tracking migration thread, Andrey Gruzdev, 2020/11/19
[PATCH v3 5/7] implementation of vm_start() BH, Andrey Gruzdev, 2020/11/19
[PATCH v3 6/7] the rest of write tracking migration code, Andrey Gruzdev, 2020/11/19
[PATCH v3 7/7] introduce simple linear scan rate limiting mechanism, Andrey Gruzdev, 2020/11/19
- Re: [PATCH v3 7/7] introduce simple linear scan rate limiting mechanism,
Peter Xu <=
Re: [PATCH v3 0/7] UFFD write-tracking migration/snapshots, Dr. David Alan Gilbert, 2020/11/24