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

[Andrii Tseglytskyi <andrii.tseglytskyi@xxxxxxxxxxxxxxx>]

Hi Stefano,

On Wed, Oct 15, 2014 at 1:55 PM, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Tue, 14 Oct 2014, Andrii Tseglytskyi wrote:
>> 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.
>
> Jan and I have been discussing this face to face yesterday (thanks to
> LinuxCon being located in Germany this year).
>
> We should keep in mind that actually both approaches can coexist and we
> should be able to choose the best one for each platform.
>

What if we try to implement both and see which one is better? But I
would prefer to implement solution without I2C in hypervisor frirst ))
And post it as RFC of course.

> But first we need to understand how much overhead the in-hypervisor
> approach would add in real world scenarios.
> Could you please provide simple measurements of how long does it take to
> make an hypercall on your platform? Use an hypercall that is more
> complex that an empty debug call, maybe XENMEM_current_reservation or
> HVMOP_get_param?  You can use the arch_timer in the guest to get the
> measurements and just post the number of ticks that it takes to complete
> the call, together with the clock frequency of the timer.

Some time ago I did measurements of IRQ latency, introduced by
hypervisor, it is pretty similar to what you are suggesting:

http://lists.xen.org/archives/html/xen-devel/2014-08/msg02963.html

> Also it would be nice to know how many I2C bus accesses per seconds the
> drivers on your board actually make. You could take a measurement by
> editing your Linux kernel and adding a counter in the I2C subsystem.
>

IMO - synchronization of I2C access between dom0 and hypervisot will be painful.

Regards,
Andrii




-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

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