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

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

Nathan,

> I'm not sure this will work if the first minor frame is also missed (which can
> happen in some odd cases).  In that scenario, you need to iterate through the
> schedule after resyncing the expected next major frame.
> 
> Building off your changes, this should work:
> 
> -    if ( sched_priv->num_schedule_entries < 1 )
> -        sched_priv->next_major_frame = now + DEFAULT_TIMESLICE;
> -    else if ( now >= sched_priv->next_major_frame )
> +    /* Switch to next major frame while handling potentially missed frames */
> +    while ( 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; -    } -    else -    { -        while
> ( (now >= sched_priv->next_switch_time) && -               
> (sched_priv->sched_index < sched_priv->num_schedule_entries) ) + +      
>  if ( sched_priv->num_schedule_entries < 1 ) +        { +           
> sched_priv->next_major_frame += DEFAULT_TIMESLICE; +           
> sched_priv->next_switch_time = sched_priv->next_major_frame; +        }
> +        else
>          {
> -            /* time to switch to the next domain in this major frame */
> -            sched_priv->sched_index++;
> -            sched_priv->next_switch_time +=
> -                sched_priv->schedule[sched_priv->sched_index].runtime;
> +            sched_priv->next_switch_time = sched_priv->next_major_frame +
> +                sched_priv->schedule[0].runtime;
> +            sched_priv->next_major_frame += sched_priv->major_frame;
>          }
>      }
> +    /* Switch minor frame or find correct minor frame after a miss */
> +    while ( (now >= sched_priv->next_switch_time) &&
> +            (sched_priv->sched_index < sched_priv->num_schedule_entries) )
> +    {
> +        sched_priv->sched_index++;
> +        sched_priv->next_switch_time +=
> +            sched_priv->schedule[sched_priv->sched_index].runtime;
> +    }
> +
> 
> Any chance you could give that a test and see if it fixes your issue?
> 
>> 
>> Can I get your advice on this subject?
>> 
>> Should you have any questions about the description, please let me know.
>> 
>> Here are the details to reproduce the issue on QEMUARM64.
> 
> I assume you are also running on hardware, but just a warning that testing 
> real
> time scheduling on qemu can be a frustrating experience.
> 
>      Nate
>> 

I appreciate your suggestion on this subject.
I'm also running xen on real hardware but qemu seems to provide worse cases to 
debug such as delayed timer interrupt and its effect.
The change you suggested works perfect and solves the issue I have observed.
As you have pointed out, my change will let the first domain run too long in 
case the first minor frame is missed, giving no chances for other domains in 
the major frame to get scheduled.

What would be the next step? Will you submit the patch or should I revise the 
patch I have already submitted with the change you suggested?

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

Thanks,
Anderson