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.c...@boeing.com/
Could you review the patch?
Thanks,
Anderson
