4 ms·

Can you elaborate on what it means for them to be kernel threads as opposed to green threads (no userspace control over when it blocks and yields?) and reentran

Can you elaborate on what it means for them to be kernel threads as opposed to green threads (no userspace control over when it blocks and yields?) and reentrant context switch routines? I read the original paper but I fear I don't have enough background to fully appreciate it.

PaulDavisThe1st 3y ago
Scheduler activations is a design that involves calling back up into the user space scheduler whenever the kernel decides to: 1. block a thread AND 2. allow the task that owns the thread to retain use of the CPU so when a thread (in user space) calls write, it ends up in the kernel, and the kernel in a traditional design would put the thread to sleep waiting on the write, invoke the scheduler to decide what should run next. With SA, the kernel first assesses whether the task can continue to use the CPU, and if so, calls the task's user-space scheduler so that it can decide which thread to run (since the user-space scheduler has better information about this). Green threads are unknown to the kernel, they play no role in such a design. Reentrant context switching is required because you can be in the middle of a context switch invoked from the user space scheduler when a h/w interrupt (incl. timers) causes the kernel to rethink what is going and rip the CPU away from the task.
- vacuity 3y ago
  Reentrancy is a nuisance. seL4 allows for the kernel to be preempted only at specific points of long running operations, which massively reduces concurrent spaghetti but also sacrifices some latency. Would the userspace program have some way of knowing about global resource contention to avoid choosing a thread suboptimally? As I understand it, SA by itself only allows userspace programs to manage their own resources efficiently.
  - PaulDavisThe1st 3y ago
    No, the kernel gets to do it's job: decide which task ("process" in classical Unix speak) should get the core based on kernel-side scheduling policies, then the task itself gets to decide which thread should run on the core. The amount of information required to correctly decide which task should get the core is too large to sensibly move across the kernel boundary, and providing read-access to it in a safe way from user space is problematic.
    - vacuity 3y ago
      Perhaps not just any program, but ideally a user could tell the OS that a certain program requires minimal latency across some cores for some duration, or that hardware TCP offload should be prioritized for a server process. Like madvise or fadvise to give the kernel suggestions for optimization, but broader.
      - PaulDavisThe1st 3y ago
        For some *nixes that already exists. But it is insufficent to provide the OS with information like "if thread N blocks for I/O, run thread T instead", particularly because in the next quantum, it might be "run thread Y instead".

PaulDavisThe1st 3y ago

Scheduler activations is a design that involves calling back up into the user space scheduler whenever the kernel decides to: 1. block a thread AND 2. allow the task that owns the thread to retain use of the CPU so when a thread (in user space) calls write, it ends up in the kernel, and the kernel in a traditional design would put the thread to sleep waiting on the write, invoke the scheduler to decide what should run next. With SA, the kernel first assesses whether the task can continue to use the CPU, and if so, calls the task's user-space scheduler so that it can decide which thread to run (since the user-space scheduler has better information about this). Green threads are unknown to the kernel, they play no role in such a design. Reentrant context switching is required because you can be in the middle of a context switch invoked from the user space scheduler when a h/w interrupt (incl. timers) causes the kernel to rethink what is going and rip the CPU away from the task.

vacuity 3y ago
Reentrancy is a nuisance. seL4 allows for the kernel to be preempted only at specific points of long running operations, which massively reduces concurrent spaghetti but also sacrifices some latency. Would the userspace program have some way of knowing about global resource contention to avoid choosing a thread suboptimally? As I understand it, SA by itself only allows userspace programs to manage their own resources efficiently.
- PaulDavisThe1st 3y ago
  No, the kernel gets to do it's job: decide which task ("process" in classical Unix speak) should get the core based on kernel-side scheduling policies, then the task itself gets to decide which thread should run on the core. The amount of information required to correctly decide which task should get the core is too large to sensibly move across the kernel boundary, and providing read-access to it in a safe way from user space is problematic.
  - vacuity 3y ago
    Perhaps not just any program, but ideally a user could tell the OS that a certain program requires minimal latency across some cores for some duration, or that hardware TCP offload should be prioritized for a server process. Like madvise or fadvise to give the kernel suggestions for optimization, but broader.
    - PaulDavisThe1st 3y ago
      For some *nixes that already exists. But it is insufficent to provide the OS with information like "if thread N blocks for I/O, run thread T instead", particularly because in the next quantum, it might be "run thread Y instead".