qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] migration: Improve accuracy of vCPU throttling


From: Peter Xu
Subject: Re: [Qemu-devel] [PATCH] migration: Improve accuracy of vCPU throttling with per-vCPU timers
Date: Wed, 19 Jun 2019 09:35:34 +0800
User-agent: Mutt/1.11.3 (2019-02-01)

On Tue, Jun 18, 2019 at 04:52:09PM +0000, Cosmin Marin wrote:
> 
> 
> On 18/06/2019, 15:51, "Peter Xu" <address@hidden> wrote:
> 
>     On Tue, Jun 18, 2019 at 12:25:43PM +0000, Cosmin Marin wrote:
>     >         Hi Peter,
>     > 
>     >         thanks for reviewing the patch. Indeed, I agree that it's 
> almost impossible to determine which solution it's better from the 
> scalability perspective. However, I feel that using per-vCPU timers is the 
> only way for ensuring correctness of the throttling ratio.
>     
>     The thing is that your patch actually contains two changes:
>     
>     1. use N timers instead of one.
>     
>     2. remove throttle_thread_scheduled check, so we do the throttle
>        always
>     
>     Here what I'm worried is that _maybe_ the 2nd item is the one that
>     really helped.
>     
>       C: The removal of *throttle_thread_scheduled* is a consequence of the 
> per-vCPU model only. In this model, each of the vCPUs schedules work just for 
> itself (as part of the timer's firing callback) - there's no global point of 
> control - therefore, the variable isn't helpful for scheduling anymore.
> 
>     Note that there is a side effect that we might queue more than one
>     work on one specific cpu if we queue it too fast, but it does not
>     block us from trying it out to identify which item (1 or 2 or both)
>     really helped here.  Then if we think that (queuing too much) is an
>     issue then we can discuss on how to fix it since current patch will
>     have this problem as well.
>     
>       C: I believe that in the per-vCPU timer implementation we cannot queue 
> more than one piece of work because, here, the vCPU queues work for itself 
> and that happens only when the timer fires - so, the two "states" - 
> scheduling and sleeping - are mutually exclusive running from the same thread 
> context. 

I think this is the place where I'm in question with - I don't think
they are using the same context.  IMO the timer will always be run in
the main thread no matter you use per-cpu timer or not, however the
sleeping part should be run on per-cpu.

A simple way to verify it would be: break at cpu_throttle_timer_tick()
to see which thread it is running in.

>     > 
>     >         It's a bit unclear to me how the throttling ratio inconsistency 
> can be fixed by using a single timer even avoiding the conditional timer 
> re-arming.  Could you provide more details about the use of a single timer ?
> 
>       C: I feel like in this case it will sleep too much running into a 
> problem similar to the one solved by 90bb0c0; under heavy throttling more 
> than one work item may be scheduled.

Right.  So I feel like we need a solution that will avoid this problem
but at the same time keep the proper accuracy of the throttling.

Thanks,

-- 
Peter Xu



reply via email to

[Prev in Thread] Current Thread [Next in Thread]