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

[Andrii Tseglytskyi <andrii.tseglytskyi@xxxxxxxxxxxxxxx>]

On Tue, Oct 14, 2014 at 4:05 PM, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
> On Tue, 2014-10-14 at 16:00 +0300, Andrii Tseglytskyi wrote:
>> 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.
>>
>
> Are audio, touchscreen and voltage control all on the same i2c bus /
> behind the same i2c controller?
>

Yes. The same bus and the same controller.

> Ian.
>
>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

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