Re: [Xen-devel] [RFC PATCH 11/13] cpufreq: add xen-cpufreq driver

[Andrii Tseglytskyi <andrii.tseglytskyi@xxxxxxxxxxxxxxx>]

On Tue, Oct 14, 2014 at 3:58 PM, Andrii Tseglytskyi
<andrii.tseglytskyi@xxxxxxxxxxxxxxx> wrote:
> On Tue, Oct 14, 2014 at 3:51 PM, Stefano Stabellini
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> On Tue, 14 Oct 2014, Jan Beulich wrote:
>>> >>> On 13.10.14 at 16:29, <andrii.tseglytskyi@xxxxxxxxxxxxxxx> wrote:
>>> >> Leaving aside that there are no real context switches between a
>>> >> domain and the hypervisor (only domains, or more precisely vCPU-s,
>>> >> get context switched), I'm not sure we need to be worried by these
>>> >> numbers. Whether they're problematic depends significantly on the
>>> >> time a full I2C command takes to issue (and perhaps complete). And
>>> >> then I'm sure you're aware that hypercalls can be batched, so as
>>> >> long as not every of these 50 commands depends on results from
>>> >> the immediately preceding one, the hypercall cost can certainly be
>>> >> amortized to a certain degree.
>>> >
>>> > But in case if each I2C command depends on results of previous one -
>>> > we can't use such calls, right? Can we really rely on this?
>>> > Some time ago I had a model (for testing which is not related to this
>>> > thread) where I sent about 20 hypercalls each second.
>>> > I observed lugs in such use cases as Video playback in domU (Android
>>> > Jelly Bean as domU). Maybe if we have only Xen and dom0 - everything
>>> > will be fine and we can send as many hypercalls as we want. But I'm
>>> > worrying in our case this will not work.
>>>
>>> If 20 hypercalls a second are a problem, then I think the device isn't
>>> capable enough in the first place to run a virtualized workload, and
>>> if it's so overloaded it's likely also not really useful to reduce the
>>> CPU frequency (as then you'd end up having even more performance
>>> problems).
>>
>> If we need 20 hypercalls a second by design, I think that we might have
>> a broken design.
>
> Agree.
>
>> One thing is requiring hypercalls for configuration,
>> such us PCI config space accesses, but requiring hypercalls to issue
>> commands to a device is very different.
>> I didn't realize that high performance devices could usually be
>> connected via I2C.
>
> This is a real example of touchscreen driver. Each scroll produces
> about 50 I2C commands. If we decide to scroll all the time (why should
> we limit this possibility?) - we will observe significant lags by this
> design.
>

Especially with Audio playback in background (which also uses I2C),
and simultaneous request of frequency / voltage change.

> Regards,
> Andrii
>
> --
>
> Andrii Tseglytskyi | Embedded Dev
> GlobalLogic
> www.globallogic.com



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel