witch_time = now - remainder + sched_priv-
> >schedule[0].runtime;
> }
>
> > The direct method suggested by Stew is preferable in the unusual case
> > where many major frames are missed. (We have only seen that happen
> > when using a debugger.)
> >
> >
On 7/14/25 11:11, Weber, Matthew wrote:
>
> > As a heads up, since this is a bit of a bigger change then some of the
> > recent
> patches, I am working on running a stress test on it, which may take some
> time.
>
> Out of curiosity, is that something we could plan to run on our end as well
>
}
>
The direct method suggested by Stew is preferable in the unusual case where
many major frames are missed. (We have only seen that happen when using a
debugger.)
To help uncover any issues like the one this patch addresses in the future we
may also want to follow up this commit with a change
On 7/10/25 2:36, Choi, Anderson wrote:
> 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?
I do not have a preference, but since you already have a patch thread started,
it is probably easiest to just hav
+Jeff
On 6/25/25 23:51, 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 "nex
9f0c658baedc ("arinc: add cpu-pool support to scheduler")
> Signed-off-by: Jan Beulich
> ---
> The Fixes: tag references where the locking was added; I can't exclude there
> was
> an issue here already before that.
> ---
> v2: Put comment in appropriate place.
>
Acked-by: Nathan Studer
On 17/03/25 05:31, Jan Beulich wrote:
> Even before its recent movement to the scheduler's private data structure it
> looks
> to have been wrong to update the field under lock, but then read it with the
> lock
> no longer held.
>
> Coverity-ID: 1644500
> Fixes: 9f0c658baedc ("arinc: add cpu-po
EN)
> >
> > panic was triggered since xfree() was called with local IRQ disabled
> > and therefore assertion failed.
> >
> > Fix this by calling xfree() after local IRQ is enabled.
> >
> > Fixes: 19049f8d796a sched: fix locking in a653sched_free_vdata()
> > Signed-off-by: Anderson Choi
>
> Reviewed-by: Juergen Gross
Acked-by: Nathan Studer
ocal variable list.
>
> Reviewed-by: Andrew Cooper
This was one of the issues Jeff fixed in this rejected patch, which we should
have split out and submitted separately upstream:
https://lists.xenproject.org/archives/html/xen-devel/2020-09/msg01318.html
Acked-by: Nathan Studer
> On 19.09.2022 04:10, Stewart Hildebrand wrote:
> > From: Stewart Hildebrand
> >
> > Add Nathan Studer as co-maintainer.
> >
> > I am departing DornerWorks. I will still be working with Xen in my next
> > role, and I still have an interest in co-maintaining
10 matches
Mail list logo
