Deos On Multicore Project

From Deos
Jump to navigationJump to search


Work is complete on this project. Follow on work is happening in Deos multi-core for AGM3

Prototype extending Honeywell's unique, patented time partitioning OS technology to make use of multi-core CPUs.

News

  • 2007-08-06: Boot now nearly complete, box boots uniprocessor to Deos. PAL work commencing.
  • 2007-07-12: Emulator and development board has arrived at Ryan's.
  • 2007-03-29: An IeWA has been submitted.
  • 2007-03-23: Effort is being turned back on. From [1] "I will talk to one of the account administrators in our building later today to understand the process. I hope to have the charge numbers set up by Monday, the start date on the plan."
  • 2006-10-06: This effort was put on hold due to lack of funding. We spent roughly two man-weeks on Phase One prior to project shut off.
  • 2006-07-10: Email sent to [2] asking for a charge code to begin Phase One work (640 man hours X $127 = $81,280).
  • 2006-04-05: From [3]: "This is important to us and we very much want it to start this year. I will pursue the funding issue."

Customers

Would apply to all customers with safety or reliability needs.

Market Segment

Business and General Aviation, Commercial, Defense & Space

Competitive Advantage

After hitting the 'clock speed wall' CPU suppliers have started delivering multi-core processors to continue increasing processor throughput. Soon it will be difficult to procure high-performance CPUs that are not multi-core. There are fundamental obstacles to deploying time partitioned systems on these CPUs. Honeywell has unique, patented 'slack stealing' technology that could be used to take advantage of these processors, perhaps years earlier than our competition could do so. The cost, size, weight, and power advantages would be large and could easily form a a key product differentiator.

Objective

Research and clarify the perceived advantages brought when using a multi-core CPU within a time and space partitioned problem domain.

Outputs

  • A better understanding of the trade-offs involved in using multi-core processors within a time and space partitioned problem domain.
  • Multi-core processor vendor selection guidelines.
  • A prototype Deos kernel executing on a multi-core processor.

2008 Tasks

Expected budget: 3200 hours

No task estimates include cert or test development.

Task Dependency Assignee Risk Original Estimate Current Estimate Elapsed Remaining
SMP feasibility determination 1080 0
Coordination with Advanced Tech 320 0
Multiple registries PCR:4112 80 0
Document application Certification considerations for multi-core 320 0
Cross core communications library. (e.g., Make IOI multi-core aware) TBD 0

We will also need some coordination trips 4, 2-person trips.

The remaining tasks will almost certainly consume more money than we have budgeted, but without knowing the outcome of the AMP/SMP determination, it is impossible to estimate the level of effort required.

Have to identify AMP vs SMP, but needs to be done either way:

  1. Design/prototype alternate time partitioning strategies.
    • budget groups
    • slack partitioning (groups, trickle down, etc.)
  2. Cache partitioning: Evaluate & Implement
    • Obstacles include: envelopes, RAM test

Only if SMP determined feasible:

  1. SMP algorithm prototyping
  2. Scheduler mods for SMP
  3. Infrastructure for N core SMP support
    • vectorize CPU class and other implementation details
    • Critical section identification and implementation.
  4. Alternative BIT implementation


Risk

  1. VFS_Project is funded (risk, otherwise will need to address boot issues and file loading on multiple cores)
  2. Book E port Project is funded so we have an 85xx BSP.
  3. Qualified kernel developers and Advanced Tech staff is small

2007 Tasks

Budget data as of 04-11-07.

Initial Labor Budget: $89,600

Emulator: $8,000

Travel: $2,200

Total Initial Budget: $99,800

YTD: $0

Current ETC: $89,600

Current EAC: $89,600


Deliveries Due Date Estimated Delivery Delivered
[1] Non-verified Kernel with PowerPC MPC8641D support. 2007-09-03 TBD TBD


Tasks for Milestone [1]

This would be an investigation phase. This phase would be used to discover and work through the issues involved in modifying the Deos kernel to support multi-core processors.

One of the main outcomes of this phase would be a narrowing of the implementation choices for the kernel. For example, it might be discovered that one could create a scheduler that spans all processor cores, or that multiple instances of the kernel, each on its own core would be more practical.

In addition, this phase would produce processor selection guidelines. These guidelines would describe those multi-core processor features that minimize the set of problems inherent in implementing time and space partitioning guarantees across multi-core processors.

Estimates are in hours

Task Assignee Risk Original Estimate Current Estimate Elapsed Remaining
Board Support Package implemented for prototype platform Ryan Roffelsen, Aaron Larson Evaluation board & Emulator availability. Other risks are interrupt architecture, shared device access (esp FLASH) and network driver. 240 240 204 36
Kernel modifications (presumed slight) for MPC8641D. Ryan Roffelsen, Aaron Larson None identified 80 80 80.5 -0.5
Kernel enhancements to prep for MC (SMP or AMP) Ryan Roffelsen None identified 260 260 201.5 58.5
Proposed AGM3 specific execution time certification mechanism. TBD None identified 20 20 12 8
Discussions with AGM team for application architecture. E.g., processor synchronization issues: kernel and application; Use of slack and/or budget groups and potential alternatives/enhancements; Potential for SMP and issues. TBD None 40 40 13 27
Totals 640 640 511 129

Informal results and musings

The Deos team has come to the conclusion that having a single Deos instance that can allocate threads across cores is not practical in the short term. Thus, the approach will be to support N Deos's for N cores (Note when N becomes sufficiently large this will not work). This support requires no kernel changes.

In this multicore environment, users will need a way to prove thread execution time budgets are set correctly. Our proposed approach is similar to the existing CPU cache trasher mechanism used today. When the PAL on one core sees the thread under measurement scheduled, it raises an interrupt to the other cores, and when the measured thread is swapped out the PAL raises a second interrupt to the other cores. When the first interrupt is raised the other cores will start trashing the bus as best they can and when the second interrupt comes in they will stop. The 7.1.0 (Agave) and later kernels' Low-Latency Kernel Mode Interrupt Feature would be well suited to perform this task.

Issues:

  1. How to verify application execution time?
  2. Is there a generic solution, or point solutions depending on HW architecture?
  3. Symetric or asymetric? Both?
    1. If symetric, what is impact of threads migrating from one core to another?
    2. If asymetric, how to handle scale from few to many processors?
    3. What CPU(s) own the interrupt controller?
  4. Is there some means other than slack to reclaim difference between guaranteed execution time and typical?
    1. If we use slack, do we need some more sophisticated slack mechanisms for partitioning slack?
  5. Are extra thread synchronization mechanisms required?
    1. Do we support schedule-before between processors?

Collaboration With Advanced Tech

Timesite Administrivia

See Timesite_Codes


Retrieved from "https://ddci.zapto.org/Wiki/index.php?title=Deos_On_Multicore_Project&oldid=12267"