WHAT WE MEAN WHEN WE SAY THAT WE ARE CORE AWARE
- Originally we thought this meant that applications would schedule to the number of cores.
- Now we believe that this means intelligently scheduling user threads onto
cores, and intelligently determining when more cores are necessary to
maintain low latency.
- Knowledge of how many cores are available moves up the stack.
- Originally that knowledge was deep down in the kenrel.
- Higher and higher in the stack.
- How high up the stack does it go?
- It goes at least to user-level threading - Arachne.
- There is a knowledge of resources that are available.
- It becomes available higher and higher up.
- Old model - Application creates threads and kernel schedules them.
- New model - Application queries number of cores and schedules based on that.
MINIMUM TIME TO SCHEDULE A THREAD ONTO ANOTHER CORE
- PACKING REPLICATED WRITES (Utilizing CPU Time while waiting on replicated writes)
- Choosing an idle core for a new task
- New task creation when all cores are busy (Slow path for user thread creation)
- Single Global Queue vs Per-Core Queues needs an experiment.
- Task migration to balance load? (may not be needed if tasks are sufficiently short-lived)
LOGICAL CONCURRENCY VS DESIRED PARALLELISM (CORE COUNT)
- When should we ask the kernel for more cores, and when should we return cores to the kernel?
TIMING GUARANTEES UNDER COOPERATIVE THREADING
- Can we have any kind of timing guarantees without preemption?
BENEFITS / SELLING POINTS / CONTRIBUTIONS
- How much of knowledge of cores should bubble up to the application?
- What kind of guidance / hints can application offer to Arachne? e.g. priorities.
Mostly Solved Issues
MINIMUM TIME TO SCHEDULE A USER THREAD ONTO ANOTHER CORE
What is the correct architecture for the fast path
...
HANDLING BLOCKING SYSCALLS
- How much or how little kernel assistance do we need?
- Current idea is to migrate all the kernel threads doing syscalls onto one
core. Then how do we ensure there is at least one kernel thread on every
other idle core?
- Requires experimentation for performance.
DATA STRUCTURE FOR TASKS THAT DO NOT YET HAVE A CORE
- Single Global Queue vs Per-Core Queues.
HOW TO INTEGRATING PRIORITIES INTO CREATE THREAD MECHANISM
LOGICAL CONCURRENCY VS DESIRED PARALLELISM (CORE COUNT)
TIMING GUARANTEES UNDER COOPERATIVE THREADING
PRIORITIES
HOW TO MAKE SCHEDULER VERY LOW LATENCY
STACK MANAGEMENT & RECYCLING
BENEFITS / SELLING POINTS / CONTRIBUTIONS
PRIORITIES OF EXISTING THREADS VS THREADS WITHOUT A CORE
HOW TO PREVENT STARVATION
LOAD BALANCING BETWEEN CORES
USER API
...
, and what is the lowest possible time to schedule to another core?
DEFINITION OF CORE AWARE
- Knowledge of the number of nature of physical cores must move up the stack from the kernel into user-level libraries and possibly into applications