Kernel Project
From DDCIDeos
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
cache Partitioning (3/1/2014)
merge in mainline changes.
memory pools: rqts, design, tests. Group discuss.
- code "done" except for:
- envelopes, RLR thinking of changing course.
- Early results from crit time kernel indicate memcpy is not good.
- access control (time for groups?) Group discuss
Proposal 1: Estimate required.
AL: will do proposal and present to group.
- actors (process) members of users, groups
- process member of <user1, group1, group2, ..., other)
- objects (memory objects, file system, events, etc.)
- file: <user1, rwx>, <group3, rwx> <other, rwx>
- read, write, execute
- Names:
- directory services.
- name to handle.
- access control.
- memory pools.
- can write to file system
- can change kernel attributes
- Interrupt ownership ()
- names used to specify permission to platform resource,
- permitted binders (permission to create processes and memory objects)
- process handle specifies permissions to objects (process, semaphore, event, mailbox, mutex, memory objects)
- Larry, can we remove this?
Proposal 2:
- Use permitted binder like mechanism to specify access control.
Proposal 3:
- Use pool size to constrain cache interference.
- IT would "shrink to fit" each memory pool quota.
- Desire vasCloneOverhead to be integrated into IT.
- Need to discuss "VAS/MOM space" + "create from parent quota" interaction that causes
Larry to need to create processes from system quota.
- writeProcessMemory() currently allocates from system quota, this causes the debugger to fail when writing to
"FLASH", even though there might be ram available in some other pool.
- Note that at this time createProcess(), createMemoryObject() and writeProcessMemory() are the only users of system quota.
- createProcess() and createMemoryObject() can be worked around via "create process template
that will never be created" hack.
- writeProcessMemory() may require some form of work around, such as "unshrink the memory object".
Proposal 4:
- Add a "system quota can allocate from this pool after first process dispatch" bit to each pool.
- new status from createProcess() "attempting to allocate system quota from system quota inhibited pool".
- new status from writeProcessMemory(), and createMemoryObject() "attempting to allocate system RAM from
system quota inhibited pool".
- How to designate pool identifiers: names, process local pool number, ??
Proposal 1:
- Define <process local pool index, ASCII name> that will end up in the process template.
- PD can name local pools, or have names refer to system names.
- AI(?) provides mapping if there are local names.
- Would like to be able to skip local name mapping (for simpler configurations).
- Multiple local indexes could refer to the same system pool.
- Perhaps introduce distinct type for local pool index.
- Status monitor would no longer have unique inverse mapping. Hmm.
- New API: "convert process local index to system pool index"
- System APIs will use system pool indexes.
- New API: "const char *convert local number to name".
- Function would be in registry library.
- merge registry library into debugger library.
- Integ tool access control
- Note: mapping kernel file sections to pools will not be in this branch/deliverable.
- Regcheck and/or CVT
- checksummer, not sure we handle non-contiguous DEOS_RAM properly.
- auto created memory objects
- More on the wikis
- https://deos.ddci.com/ddciWiki/Deos_Cache_Partitioning
- https://deos.ddci.com/Wiki/Kernel_Project/Memory_Pools
rename UG/DDD to "Deos kernel..." GK:
complete MIPS: BIT, ELF (rqts) AL:
porting all tests to MIPS.
- All architecture specific #ifdefs should have else error clause.
- What are the plans for a test team? Bill and Ole.
- Need a "gold standard" example test.
- Someone triage, then telecon discuss.
653 features:
- Finish requirements (RLR and AL).
- Tests implement and review
- WAT,
- access control on setKernelAttributesEx()
MIPS errata analysis.
Eliminate nested mutexes, or drop slack interaction. Discuss with Larry. Marketing says "huh?, sure.". Perhaps move to multi-core.
Eliminate checksummer? Larry?
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.
