[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH v2] xen/arinc653: fix delay in the start of major frame


  • To: Anderson Choi <anderson.choi@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
  • Date: Thu, 17 Jul 2025 09:20:40 -0400
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=boeing.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=k+3G5X7FVn8MiJi955OOZDwsokiHYaq1BBDMSaA91ro=; b=ZXCGTIDUDjoq/faufZm6/50/oOMGkW8TIm2yIofqFVhf3MjUh97JNhnKw5XScl2fVkl/479Bd/hlrFr5njq8Lx4p/CG1YdfcAqm8nI0uZ09CaEcALOsY88P1JehAzbdZxLfxm0SBIZYZ5+UGxv90mnROxjDa5Y29OtQ5B71ffwKKIqfDJmtgwd2zOQ9cW0Yay+ZLVJ4RAjfajyActiTQAe2bL0tqDEVWaKZG+38oj6WolDwl1mbNrCkFHyFMCc64Bxv8XkFECnNgJ/DKSW/fWReDmKAQvk42V8N+2cF1KJqzhEOVUlKy5zYI9A930wwxmJDxPoMYBKLcrPWFfFnu4g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IVH9yQgWyFNedzB4SjS6WZuxYi1quBtn7IpNIS6KJIrJ1WeHyN5x7z3IWkEnKXi2+Le/Uyc4vm5/Zl9ZXUjSHLe6EHphpAly9zv1if7Oy1WhN7+llRVrYo7u4I4fHGaaV2mE7tzQ33dsdDf7XWpFn1avQPXNdhTlFnFhbzEkaSSyA7U46bRJBsPW24wXCOduBcHwn0nDwID1krMQfCxDoqf7Zi1CF5HgQi24pH9UJbC2bvKtFb3WDnqT6G/D6xSKG5EW+A0Gw1kz7AV2WmIKLCD0qyNs3pKymlkNGWs35NDVQVuvn4Of/2VbmXR41cqpZyPDDOt/uk0Rxz7S70AtnQ==
  • Cc: <matthew.l.weber3@xxxxxxxxxx>, <joshua.c.whitehead@xxxxxxxxxx>, Nathan Studer <nathan.studer@xxxxxxxxxxxxxxx>, Stewart Hildebrand <stewart@xxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, George Dunlap <gwd@xxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 17 Jul 2025 13:20:56 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 7/14/25 23:16, Anderson Choi wrote:
> ARINC653 specificaion requires partition scheduling to be deterministic

s/specificaion/specification/

> and periodic over time.
> 
> However, the use of current timestamp (now) as the baseline to calculate
> next_major_frame and next_switch_time introduces a delay in the start of
> major frame at every period, which breaks determinism and periodicity in
> partition scheduling.
> 
> For example, we observe 3.5 msec of accumulated delay at the 21st major
> frame with the following configuration.
> 
> Target : qemuarm64
> xen version : 4.19 (43aeacff86, x86/IRQ: constrain creator-domain-ID 
> assertion)
> dom1 : 10 msec runtime
> dom2 : 10 msec runtime
> 
> $ a653_sched -p Pool-arinc dom1:10 dom2:10
> 
> 0.014553536 ---x d?v? runstate_change d1v0 runnable->running //1st major
> frame
> 0.034629712 ---x d?v? runstate_change d1v0 runnable->running //2nd major
> frame
> <snip>
> 0.397747008 |||x d?v? runstate_change d1v0 runnable->running //20th
> major frame
> 0.418066096 -||x d?v? runstate_change d1v0 runnable->running //21st
> major frame
> 
> This is due to an inherent delta between the time value the scheduler timer
> is programmed to be fired with and the time value the schedule function
> is executed.
> 
> Another observation that breaks the deterministic behavior of partition
> scheduling is a delayed execution of schedule(); It was called 14 msec
> later than programmed.
> 
> 1.530603952 ---x d?v? runstate_change d1v0 runnable->running
> 1.564956784 --|x d?v? runstate_change d1v0 runnable->running
> 
> Enforce the periodic behavior of partition scheduling by using the value
> next_major_frame as the base to calculate the start of major frame and
> the next domain switch time.
> 
> Per discussion with Nathan Studer, there are odd cases the first minor
> frame can be also missed. In that sceanario, iterate through the schedule 
> after resyncing

s/sceanario/scenario/

> the expected next major frame.
> 
> Signed-off-by: Anderson Choi <anderson.choi@xxxxxxxxxx>
> Suggested-by: Nathan Studer <nathan.studer@xxxxxxxxxxxxxxx>

I think this wants a Fixes: tag:

Fixes: 22787f2e107c ("ARINC 653 scheduler")

> 
> ---
> Changes in v2:
> - Changed the logic to resync major frame and to find correct
>   minor frame after a miss suggested by Nathan
> ---
>  xen/common/sched/arinc653.c | 38 ++++++++++++++++++++-----------------
>  1 file changed, 21 insertions(+), 17 deletions(-)
> 
> diff --git a/xen/common/sched/arinc653.c b/xen/common/sched/arinc653.c
> index 930361fa5c..a7937ed2fd 100644
> --- a/xen/common/sched/arinc653.c
> +++ b/xen/common/sched/arinc653.c
> @@ -526,27 +526,31 @@ a653sched_do_schedule(
>  
>      spin_lock_irqsave(&sched_priv->lock, flags);
>  
> -    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 )
>          {
> -            /* 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_major_frame += DEFAULT_TIMESLICE;
> +            sched_priv->next_switch_time = sched_priv->next_major_frame;
>          }
> +        else
> +        {
> +            sched_priv->next_switch_time = sched_priv->next_major_frame +
> +                sched_priv->schedule[0].runtime;
> +            sched_priv->next_major_frame += sched_priv->major_frame;
> +        }
> +    }

There's no need for the above loop, this can be fixed by subtracting the
remainder (modulus major_frame). E.g.:

    if ( now >= sched_priv->next_major_frame )
    {
        s_time_t major_frame = sched_priv->num_schedule_entries < 1
                               ? DEFAULT_TIMESLICE
                               : sched_priv->major_frame;
        s_time_t remainder = (now - sched_priv->next_major_frame) % major_frame;

        sched_priv->sched_index = 0;
        sched_priv->next_major_frame = now - remainder + major_frame;
        sched_priv->next_switch_time = now - remainder +
                                       (sched_priv->num_schedule_entries < 1
                                        ? DEFAULT_TIMESLICE
                                        : sched_priv->schedule[0].runtime);
    }

The commit description may want some minor updating to reflect this.

> + 
> +    /* 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;
>      }
>  
>      /*




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.