RE: Re: Discussion on the delayed start of major frame with ARINC653 scheduler

["Choi, Anderson" <Anderson.Choi@xxxxxxxxxx>]

Stewart,

> 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?

I appreciate your feedback on this subject. Here's the link to the patch I have 
submitted.

https://patchwork.kernel.org/project/xen-devel/patch/26f4fb409f03cb221a98692c4f291756d9cc26ae.1751948342.git.anderson.choi@xxxxxxxxxx/

Could you review the patch?

Thanks,
Anderson