Re: [RFC PATCH v2 10/12] cpufreq: add dom0-cpufreq driver

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

On Thu, 2014-10-23 at 12:49 +0300, Oleksandr Dmytryshyn wrote:
> On Wed, Oct 22, 2014 at 5:00 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2014-10-22 at 16:24 +0300, Oleksandr Dmytryshyn wrote:
> >> On Wed, Oct 22, 2014 at 2:00 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > On Wed, 2014-10-22 at 10:30 +0100, Jan Beulich wrote:
> >> >> >>> On 22.10.14 at 10:43, <oleksandr.dmytryshyn@globallogic.com> wrote:
> >> >> > On Fri, Oct 17, 2014 at 4:03 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >> >> >>>>> On 16.10.14 at 13:27, <oleksandr.dmytryshyn@globallogic.com> wrote:
> >> >> >>> +static void notify_cpufreq_domains(void)
> >> >> >> Why "domains", not "hwdom"? You don't really want to send this
> >> >> >> to other than the hardware domain I hope.
> >> >> > All domains (not only hwdomain) should receive this interrupt.
> >> >> > In case is hwdomain is Linux kernel it can automaticaly recalculate
> >> >> > jiffies. But other domains should recalculate jiffies too. I'll
> >> >> > implement this mechanism a bit later.
> >> >>
> >> >> This needs more explanation then: If all domains need to do
> >> >> adjustments when the frequency changes, there's something
> >> >> wrong here imo. Such changes are supposed to be visible to
> >> >> the hypervisor only (with, in the case here, assistance - but
> >> >> nothing else - by the hardware domain).
> >> >
> >> > Guests should be using the arch/generic timers as their time source.
> >> > This is required by the hardware to increment at a fixed frequency, so
> >> > guests shouldn't need to be aware of the change to the underlying
> >> > processor clock, at least not for timekeeping/jiffies purposes.
> >> >
> >> > The timers are allowed to increment by larger amounts less frequency in
> >> > lower power modes, i.e. +=4 every 4 ticks. Guests shouldn't need to
> >> > adjust anything for this though IMHO.
> >> There are many functions which are using jiffies. What about them?
> >> All those functions will measure time not correctly if frequency
> >> of the microprocessor will change.
> >
> > Jiffies is based on the timer tick, isn't it? Therefore it is ultimately
> > based on the arch timer.
> Even if jiffies is ticked from the timer and what about
> 'loops_per_jiffy' variable(s)? This variable is declared for ARM and it
> should be recalculated in every change of frequency.

AFAICT it is unused if arch_timers are in use, via the call to
register_current_timer_delay which takes the loops_per_jiffy based delay
function out of the equation.

Rather than making me run around pointing out why each potential use of
LPJ is not relevant in practice one by one please instead point out an
actual case where you see it being used in practice in a Xen guest using
arch timers.

Ian.