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 

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)
• Elbert++ (A baseline following Elbert. Unverified release ~ 8/1/2012, Verified Q2/2013)
  • E500 SPE support (kernel only, not math), (needed by malabi)
  • Complete Sybil (desired by malabi)
• Fourpeaks-- Unverified release ~ 8/28/2012, Verified ??/2013
  • 653/WAT (torta)
• Fourpeaks release schedule depends on Chino
  • MIPS (works on VM now, need some devel to work on real HW)
  • Deos Cache Partitioning
  • Might need fast packet as well.

Roadmap

These are the substantive changes that have been proposed for the kernel, and our current thinking of their release schedule.

• Complete Elbert verification.
  • Merge changes into cachePartitioning and multi-core branches
• Are there changes made by Honeywell that need to be brought forward?
• Four peaks
  • Verification.
  • What is plan w.r.t. windows? Retain existing SCM version, or backport multi-core?
• Multicore (on legacy wiki)
  • 2013 project numbers have been assigned.
• Memory Pools PO imminent

---

• ARM support
• More than 32-bit Deos RAM and FLASH
• Make HAL a separately loaded .so (to speed processor porting).

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.
  - 

5200 port (sales prospect).

more complete support for 64-bit physical addressing.


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.


ARM K61, does it have MMU?  RLR says it does not.  Tell Ole.

other committments:
  GK  CVTs
  RLF 653 runtime verf support.