Scheduling and the periodic timer

Scheduling and the periodic timer

[Juergen Gross]

While working on my core scheduling series I stumbled over the periodic
timer. Could it be this timer never worked correctly?

When the vcpu with an active periodic timer is running everything seems
to be fine. But when not running the timer is stopped in schedule(). So
a vcpu going to idle relying to be woken up by the periodic timer will
remain sleeping until another event is happening. The periodic timer
won't fire as it is stopped.

The periodic timer is used via VCPUOP_set_periodic_timer only, and
today's Linux kernel isn't using it at all. So I guess this timer not
really working as it should is no big issue.

I just wanted to mention that fact, maybe someone is keen repairing
this issue.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Scheduling and the periodic timer

[Andrew Cooper]

On 01/02/2019 07:26, Juergen Gross wrote:
> While working on my core scheduling series I stumbled over the periodic
> timer. Could it be this timer never worked correctly?
>
> When the vcpu with an active periodic timer is running everything seems
> to be fine. But when not running the timer is stopped in schedule(). So
> a vcpu going to idle relying to be woken up by the periodic timer will
> remain sleeping until another event is happening. The periodic timer
> won't fire as it is stopped.
>
> The periodic timer is used via VCPUOP_set_periodic_timer only, and
> today's Linux kernel isn't using it at all. So I guess this timer not
> really working as it should is no big issue.
>
> I just wanted to mention that fact, maybe someone is keen repairing
> this issue.

Do you mean to say that, after the next schedule(), any configured
periodic timer ceases to provide further interrupts?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Scheduling and the periodic timer

[Jan Beulich]

>>> On 01.02.19 at 08:26, <jgross@suse.com> wrote:
> While working on my core scheduling series I stumbled over the periodic
> timer. Could it be this timer never worked correctly?
> 
> When the vcpu with an active periodic timer is running everything seems
> to be fine. But when not running the timer is stopped in schedule(). So
> a vcpu going to idle relying to be woken up by the periodic timer will
> remain sleeping until another event is happening. The periodic timer
> won't fire as it is stopped.
> 
> The periodic timer is used via VCPUOP_set_periodic_timer only, and
> today's Linux kernel isn't using it at all. So I guess this timer not
> really working as it should is no big issue.

Interesting. Our kernels have been using it until SLE11 SP1, as
did the old 2.6.18 one that all of our old kernels were derived
from. Yet the same code is present already in 3.2.0's schedule().
Are you sure this timer is meant to wake the vCPU at the set
rate, rather than just surfacing events if the vCPU is running?
Looking at vcpu_periodic_timer_work()'s calculation of the
next event time also suggests to me that there's no guarantee
that the event will indeed surface at the set rate.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Scheduling and the periodic timer

[Juergen Gross]

On 01/02/2019 10:40, Andrew Cooper wrote:
> On 01/02/2019 07:26, Juergen Gross wrote:
>> While working on my core scheduling series I stumbled over the periodic
>> timer. Could it be this timer never worked correctly?
>>
>> When the vcpu with an active periodic timer is running everything seems
>> to be fine. But when not running the timer is stopped in schedule(). So
>> a vcpu going to idle relying to be woken up by the periodic timer will
>> remain sleeping until another event is happening. The periodic timer
>> won't fire as it is stopped.
>>
>> The periodic timer is used via VCPUOP_set_periodic_timer only, and
>> today's Linux kernel isn't using it at all. So I guess this timer not
>> really working as it should is no big issue.
>>
>> I just wanted to mention that fact, maybe someone is keen repairing
>> this issue.
> 
> Do you mean to say that, after the next schedule(), any configured
> periodic timer ceases to provide further interrupts?

No, it just won't wake the vcpu up. As soon as the vcpu is running the
timer will run again and it will provide interrupts again. In case an
interrupt was due during the vcpu was not running that interrupt will
be delivered as soon as the vcpu starts running again.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Scheduling and the periodic timer

[Juergen Gross]

On 01/02/2019 10:50, Jan Beulich wrote:
>>>> On 01.02.19 at 08:26, <jgross@suse.com> wrote:
>> While working on my core scheduling series I stumbled over the periodic
>> timer. Could it be this timer never worked correctly?
>>
>> When the vcpu with an active periodic timer is running everything seems
>> to be fine. But when not running the timer is stopped in schedule(). So
>> a vcpu going to idle relying to be woken up by the periodic timer will
>> remain sleeping until another event is happening. The periodic timer
>> won't fire as it is stopped.
>>
>> The periodic timer is used via VCPUOP_set_periodic_timer only, and
>> today's Linux kernel isn't using it at all. So I guess this timer not
>> really working as it should is no big issue.
> 
> Interesting. Our kernels have been using it until SLE11 SP1, as
> did the old 2.6.18 one that all of our old kernels were derived
> from. Yet the same code is present already in 3.2.0's schedule().
> Are you sure this timer is meant to wake the vCPU at the set
> rate, rather than just surfacing events if the vCPU is running?
> Looking at vcpu_periodic_timer_work()'s calculation of the
> next event time also suggests to me that there's no guarantee
> that the event will indeed surface at the set rate.

That's correct. The set rate just is the minimum time between two
interrupts.

The usability of such a timer is questionable in the best case IMO.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Scheduling and the periodic timer

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1891 bytes --]

On Fri, 2019-02-01 at 10:59 +0100, Juergen Gross wrote:
> On 01/02/2019 10:50, Jan Beulich wrote:
> > > > > On 01.02.19 at 08:26, <jgross@suse.com> wrote:
> > > 
> > > The periodic timer is used via VCPUOP_set_periodic_timer only,
> > > and
> > > today's Linux kernel isn't using it at all. So I guess this timer
> > > not
> > > really working as it should is no big issue.
> > 
> > Interesting. Our kernels have been using it until SLE11 SP1, as
> > did the old 2.6.18 one that all of our old kernels were derived
> > from. Yet the same code is present already in 3.2.0's schedule().
> > Are you sure this timer is meant to wake the vCPU at the set
> > rate, rather than just surfacing events if the vCPU is running?
> > Looking at vcpu_periodic_timer_work()'s calculation of the
> > next event time also suggests to me that there's no guarantee
> > that the event will indeed surface at the set rate.
> 
> That's correct. The set rate just is the minimum time between two
> interrupts.
> 
> The usability of such a timer is questionable in the best case IMO.
> 
Yes, I vaguely recall discussing about this with someone, and the
outcome being <<Well, everyone should be using the single-shot timer
anyway, these days>>, and then we probably dropped the ball (I can't
find the thread right now, maybe it was on IRC). :-(

IAC, I do agree that it does not make any sense to stop the timer for
the vcpu being descheduled. And we really should either fix this... or
we can get just get rid of the timer entirely, as it's basically
delivering events at pseudo-random rate! :-O

I can look into that.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel