Kernel Project

The non-distribution specific Deos Kernel project.

Description

This is a placeholder for the work performed across multiple kernel experimental and verification baselines. I.e., roadmap sorts of topics.

Distribution   Branch
 Elbert        mainline
 FourPeaks     cachePartitioning 
 multi-core    multi-core

Perhaps this would be better handled as a "product" page like we did on the legacy wiki.

These are the current Kernel projects in work:

• Elbert (AKA 7.10)
  • 36-bit Support (Deos RAM and FLASH still limited to 32-bit).
  • Part of Sybil
  • Thread aware debugging. (needed by torta)
• Fourpeaks-- Unverified Full funcionality release ??/2013
• Fourpeaks release End of March 2014
  • 653/WAT (torta)
  • Complete Sybil (desired by malabi)
  • MIPS
  • Deos Cache Partitioning
  • Might need fast packet as well.
• Multicore (on legacy wiki)

Roadmap

These are the substantive changes that have been proposed for the kernel that are not yet in a project.

• Are there changes made by Honeywell that need to be brought forward?
• Deos_ARM_Port
• More than 32-bit Deos RAM and FLASH
• Make HAL a separately loaded .so (to speed processor porting).
• E500 SPE support (kernel only, not math), (needed by malabi)
• 5200 port (sales prospect).

Notes from May 2013 kernel team meeting

multi-core
  Finish scheduler
   - Is IPI to self allowed?  Affects window scheduler.
   - Is there a change to 4p raiseWindowTimer IPI to make forward compatibility easier?
   - access control on execution groups.
   - Add execution group level "imprecise waiter list per scheduler", or perhaps just counter, in the group.
     - Scheduler would look at global counter and execution group local counter,
       if either is different, merge the scheduler's imprecise waiter list

       AL: what does it mean "in the group"?  semaphores don't have a group, neither do schedulers.

   - Minimizing IPIs is preferred even if it extends criticals, over broadcast IPIs
     - Providing bounded interference (e.g., POSIX scheduler causing unaccounted overhead in an RMA scheduler.
     - Also prevents stacked criticals for global imprecise waiters.
   - IPIs should only be required in a multi-core aware system.  I.e., no IPI on unicore.  Design desirement.
   - Bounding fiber blocking times and overheads. (ugg).
   - Perhaps schedule after threads and the SOP could add to the front of the ready list.
     - Won't work if the head of the ready list has a mutex locked.
   - All RMA windows have to have an overhead to "bonus" the final thread that is interrupted at a window boundary.
   - When a window stops, make sure the thread timer is read "early" so that
     window associated overheads are not charged to the thread in the preceding
     window.
   - Zero width window not permitted.  If you have a "may finish early" followed by a "may
     NOT start early", you have to add a minimal width RMA window between them
   - Desire to continue support for system ticks that are faster than fastest rate.
   - Fix "Deos Windows must be at least as frequent as the tick rate."
     to: "RMA Windows must be at least as frequent as the fastest rate."
   - Window has "is start of system tick" and "slowest RMA rate that starts now" attributes.
   - "Track time donated from other windows. (slack)" window scheduler protocol must tell scheduler "how early did you start".
   - Window scheduler how to get to idle, RLR says on a wiki.

   - Window scheduler "which cores are idle bitmap" perhaps can change to a count, and or
     use algorithm on https://deos.ddci.com/Wiki/Deos_Multicore_Design perhaps modified to
     use a "context switch count" variable to know when to re-evaluate quiescence.

Window scheduler:
  - delete:  handles gray area around zero duration filler window, if not enough time to switch to it 
  - allow registering window activation handler
    - Does it run in user or supervisor mode?  Alternately, what APIs can be used?
    - If managed as an exception to threads, is it "all threads first time activated in
      this window", or "first thread in a process first time activated in this window".

  Finish x86 HAL
   - "Send IPI to specific core" to implement raiseKernelException and exceptions, note that we'll need both sync and asynch.
  PPC port
  One or more than one RMA scheduler?
  MPC2041 multi-core BSP
  qemu-ppc multi-core BSP?
  multi-core verf strategy
  POSIX/FACE something or other.
  Bounding worst case blocking time on master (and slave(s))?
  Minimize criticals, merge criticals, etc., to minimize blocking time.
  MIPS kernel dead ended?  Ask Marketing?
  
One big lock vs finer grained.
  - One lock per securable kernel interface object.
  - uh, stumped.
  - Perhaps use one big lock algorithm on master, fine grained two phase commit (or similar) on slaves.
  - Rather than ensure stuff, provide user enough detail that they can do the analysis.

To SMP or not
Slave core blocking.

FACE multiple schedulers per window sometimes, others only one..
  - Try to kill this at FACE committee.
  - Ok to have consistent sets of partitions/processes, varying sets not acceptable.
  - Speak to Art.

One active window schedule per kernel instance, or one per core?
  - We will do one per kernel instance.

GK & RLR do a brown bag on structural coverage tips and tricks.
  do-while
  case statements
  duplicated branches, fixed with compiler switch change -fno-re????
  what code mods were made to fix things.

other committments:
  GK  CVTs
  RLF 653 runtime verf support.