Re: [PATCH 5/5] sched/arinc653: Implement CAST-32A multicore scheduling

[Dario Faggioli <dfaggioli@xxxxxxxx>]

On Fri, 2020-09-18 at 16:03 -0400, Jeff Kubascik wrote:
> On 9/17/2020 1:30 PM, Dario Faggioli wrote:
> > On Thu, 2020-09-17 at 15:59 +0000, Stewart Hildebrand wrote:
> > > 
> > And don't think only to the need of writing the code (as you kind
> > of
> > have it already), but also to testing. As in, the vast majority of
> > the
> > core-scheduling logic and code is scheduler independent, and hence
> > has
> > been stressed and tested already, even by people using schedulers
> > different than ARINC.
> 
> When is core scheduling expected to be available for ARM platforms?
> My
> understanding is that this only works for Intel.
> 
As soon as "someone" actually tests it, and tell us how _well_ it works
*already*.  :-) :-P :-)

IIRC, there should be no (or really really few) code changes necesssary
for doing that.

> With core scheduling, is the pinning of vCPUs to pCPUs configurable?
> Or can the
> scheduler change it at will? One advantage of this patch is that you
> can
> explicitly pin a vCPU to a pCPU. This is a desirable feature for
> systems where
> you are looking for determinism.
> 
It certainly is. Now, as I think you know very well, some of the logic
for honoring the requested pinning is implemented inside each scheduler
(i.e., credit.c, credit2.c, etc).

Therefore, you *may* need to do the same in arinc653, probably
similarly to what you were doing in this patch (so there may indeed be
parts of this patch that are still necessary, but I still expect it to
become rather smaller and less intrusive).

But yeah, all the generic stuff is there already, and core-scheduling
does not prevent it to be used.

> There are a few changes in this patch that I think should be pulled
> out if we go
> the path of core scheduling. 
>
Sure, I totally agree.

> For instance, it removes a large structure from
> being placed on the stack. It also adds the concept of an epoch so
> that the
> scheduler doesn't drift (important for ARINC653) and can recover if a
> frame is
> somehow missed (I commonly saw this when using a debugger). I also
> observed the
> occasional kernel panic when using xl commands which was fixed by
> improving the
> locking scheme.
> 
Exactly, all these things looked legit and good to me. And they can be
pulled out in one or more other patches. Plus, you probably also need a
patch with the pinning bits.

But you should be able to get rid of all the parts that tries to make
sure that only one domain is scheduled at any given time.

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)

Attachment: signature.asc
Description: This is a digitally signed message part