[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


> 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



Andrii Tseglytskyi | Embedded Dev

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.