On 6/25/25 23:50, Choi, Anderson wrote:
> We are observing a slight delay in the start of major frame with the current
> implementation of ARINC653 scheduler, which breaks the determinism in the
> periodic execution of domains.
>
> This seems to result from the logic where the variable "next_major_frame" is
> calculated based on the current timestamp "now" at a653sched_do_schedule().
>
> static void cf_check
> a653sched_do_schedule(
> <snip>
> else if ( now >= sched_priv->next_major_frame )
> {
> /* time to enter a new major frame
> * the first time this function is called, this will be true */
> /* start with the first domain in the schedule */
> sched_priv->sched_index = 0;
> sched_priv->next_major_frame = now + sched_priv->major_frame;
> sched_priv->next_switch_time = now + sched_priv->schedule[0].runtime;
> }
>
> Therefore, the inherent delta between "now" and the previous
> "next_major_frame" is added to the next start of major frame represented by
> the variable "next_major_frame".
>
> And I think the issue can be fixed with the following change to use
> "next_major_frame" as the base of calculation.
>
> diff --git a/xen/common/sched/arinc653.c b/xen/common/sched/arinc653.c index
> 930361fa5c..15affad3a3 100644
> --- a/xen/common/sched/arinc653.c
> +++ b/xen/common/sched/arinc653.c
> @@ -534,8 +534,11 @@ a653sched_do_schedule(
> * the first time this function is called, this will be true */
> /* start with the first domain in the schedule */
> sched_priv->sched_index = 0;
> - sched_priv->next_major_frame = now + sched_priv->major_frame;
> - sched_priv->next_switch_time = now + sched_priv->schedule[0].runtime;
> +
> + do {
> + sched_priv->next_switch_time = sched_priv->next_major_frame +
> sched_priv->schedule[0].runtime;
> + sched_priv->next_major_frame += sched_priv->major_frame;
> + } while ((now >= sched_priv->next_major_frame) || (now >=
> sched_priv->next_switch_time));
> }
> Else
>
> Can I get your advice on this subject?
The drift you're observing is a known issue with the scheduler. The next
major frame shouldn't be calculated with the "now" variable. It should
rather be calculated by adding the major frame period. Also, as your
code suggests, it should take into account edge cases where "now" may be
in the far future. There is another instance of next_major_frame being
calculated using "now" just above. Are you willing to submit a patch?
