Re: Re: [patch 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.

Re: Re: [patch 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.

[Jeremy Fitzhardinge]

Keir Fraser wrote:
> This initial patchset does not include save/restore support anyway, so in
> fact it would be consistent to have CONFIG_PREEMPT configurable. I'm sure
> that we are going to have some nasty bugs to fix up as a result, but we
> can't fix them until we find them! Then we can convert our save/restore code
> to use the freezer before submitting it for inclusion.
OK.  So that makes the only config restriction the 100Hz ticks.

    J

Re: [Xen-devel] Re: [patch 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.

[Keir Fraser]

On 16/2/07 17:46, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:

> Keir Fraser wrote:
>> This initial patchset does not include save/restore support anyway, so in
>> fact it would be consistent to have CONFIG_PREEMPT configurable. I'm sure
>> that we are going to have some nasty bugs to fix up as a result, but we
>> can't fix them until we find them! Then we can convert our save/restore code
>> to use the freezer before submitting it for inclusion.
> OK.  So that makes the only config restriction the 100Hz ticks.

We can extend the Xen timer interface quite easily and get rid of this one
too. In fact it doesn't *much* matter if the CONFIG_HZ differs from the Xen
ticker rate -- we modified the Linux timer ISR to handle timer interrupts at
arbitrary times already. The only drawback is that jiffies updates in burts
if CONFIG_HZ is higher than the actual tick rate, and this can affect some
calibration constants and cause Linux to print out some weird values at
start-of-day.

 -- Keir

Re: [Xen-devel] Re: [patch 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.

[Keir Fraser]

On 16/2/07 17:46, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:

> Keir Fraser wrote:
>> This initial patchset does not include save/restore support anyway, so in
>> fact it would be consistent to have CONFIG_PREEMPT configurable. I'm sure
>> that we are going to have some nasty bugs to fix up as a result, but we
>> can't fix them until we find them! Then we can convert our save/restore code
>> to use the freezer before submitting it for inclusion.
> OK.  So that makes the only config restriction the 100Hz ticks.

We can extend the Xen timer interface quite easily and get rid of this one
too. In fact it doesn't *much* matter if the CONFIG_HZ differs from the Xen
ticker rate -- we modified the Linux timer ISR to handle timer interrupts at
arbitrary times already. The only drawback is that jiffies updates in burts
if CONFIG_HZ is higher than the actual tick rate, and this can affect some
calibration constants and cause Linux to print out some weird values at
start-of-day.

 -- Keir

Re: Re: [patch 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.

[Jeremy Fitzhardinge]

Keir Fraser wrote:
> We can extend the Xen timer interface quite easily and get rid of this one
> too. In fact it doesn't *much* matter if the CONFIG_HZ differs from the Xen
> ticker rate -- we modified the Linux timer ISR to handle timer interrupts at
> arbitrary times already. The only drawback is that jiffies updates in burts
> if CONFIG_HZ is higher than the actual tick rate, and this can affect some
> calibration constants and cause Linux to print out some weird values at
> start-of-day.
>   

I was wondering what would happen if we tried that.  I guess its
equivalent to having stolen time between each Xen tick.

    J

Re: Re: [patch 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.

[Zachary Amsden]

Keir Fraser wrote:
> On 16/2/07 17:46, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:
>
>   
>> Keir Fraser wrote:
>>     
>>> This initial patchset does not include save/restore support anyway, so in
>>> fact it would be consistent to have CONFIG_PREEMPT configurable. I'm sure
>>> that we are going to have some nasty bugs to fix up as a result, but we
>>> can't fix them until we find them! Then we can convert our save/restore code
>>> to use the freezer before submitting it for inclusion.
>>>       
>> OK.  So that makes the only config restriction the 100Hz ticks.
>>     
>
> We can extend the Xen timer interface quite easily and get rid of this one
> too. In fact it doesn't *much* matter if the CONFIG_HZ differs from the Xen
> ticker rate -- we modified the Linux timer ISR to handle timer interrupts at
> arbitrary times already. The only drawback is that jiffies updates in burts
> if CONFIG_HZ is higher than the actual tick rate, and this can affect some
> calibration constants and cause Linux to print out some weird values at
> start-of-day.
>   

That's why we'd very much like to get a get_cpu_speed paravirt-op 
implemented.  I think this would be useful to work around these problems 
for Xen as well.

Zach

Re: Re: [patch 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.

[Rik van Riel]

Dan Hecht wrote:

> Yes, and regardless of whether you run your periodic timer slower than 
> HZ, calibrating time in a VM is always difficult due to the fact the 
> kernel is time sharing the physical cpu.  Why not just ask the 
> underlying hypervisor?

Upstream Xen does just that.

I'm guessing we'll want something similar for KVM paravirt.

-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.