On Fri, Oct 18, 2024 at 3:33 AM Peter Xu wrote:
> On Thu, Oct 17, 2024 at 02:42:54PM +0800, yong.hu...@smartx.com wrote:
> > +void cpu_throttle_dirty_sync_timer_tick(void *opaque)
> > +{
> > +static uint64_t prev_sync_cnt;
>
> We may need to reset this in case migration got cancelled and invo
Peter Xu writes:
> On Thu, Oct 17, 2024 at 02:42:54PM +0800, yong.hu...@smartx.com wrote:
>> +void cpu_throttle_dirty_sync_timer_tick(void *opaque)
>> +{
>> +static uint64_t prev_sync_cnt;
>
> We may need to reset this in case migration got cancelled and invoked
> again, to make sure it keeps
On Thu, Oct 17, 2024 at 02:42:54PM +0800, yong.hu...@smartx.com wrote:
> +void cpu_throttle_dirty_sync_timer_tick(void *opaque)
> +{
> +static uint64_t prev_sync_cnt;
We may need to reset this in case migration got cancelled and invoked
again, to make sure it keeps working in the 2nd run.
> +
yong.hu...@smartx.com writes:
> From: Hyman Huang
>
> When VM is configured with huge memory, the current throttle logic
> doesn't look like to scale, because migration_trigger_throttle()
> is only called for each iteration, so it won't be invoked for a long
> time if one iteration can take a lon
From: Hyman Huang
When VM is configured with huge memory, the current throttle logic
doesn't look like to scale, because migration_trigger_throttle()
is only called for each iteration, so it won't be invoked for a long
time if one iteration can take a long time.
The periodic dirty sync aims to f
