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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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

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