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

[Ian Campbell <ian.campbell@citrix.com>]

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@globallogic.com> wrote:
> > On Tue, Oct 14, 2014 at 3:51 PM, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> >> On Tue, 14 Oct 2014, Jan Beulich wrote:
> >>> >>> On 13.10.14 at 16:29, <andrii.tseglytskyi@globallogic.com> 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?

Ian.