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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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.

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.
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.

Thanks!

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