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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.10.14 at 16:29, <andrii.tseglytskyi@xxxxxxxxxxxxxxx> wrote:
> On Mon, Oct 13, 2014 at 5:11 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 13.10.14 at 15:38, <andrii.tseglytskyi@xxxxxxxxxxxxxxx> wrote:
>>> It should be noticed that sometimes I2C transactions require platform
>>> specific IPs.
>>> For example OMAP3+ platforms contain HW spinlock IP (which is a real
>>> HW module with its own clocks).
>>> Each i2c_send call must acquire this HW spinlock. And this is
>>> something we can't implement in Xen hypervisor.
>>
>> Do you really mean "can't", or rather "don't want to"? It's very
>> hard for me to imagine something that absolutely can't be done
>> in the hypervisor.
>>
> 
> I mean that we must deal with platform specific IP in this case. This
> is dependency from specific HW, and driver will not be simple and
> generic.
> Also I think such interactions are out of scope for hypervisor.
> What do you think?

Nothing is really out of scope for the hypervisor. It's always a
matter of judgment, and looking at the Linux i2c driver subtree I
don't view its size as problematic (the more that I don't think
you'd need all of it).

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

Jan


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