Skip to content

Scheduler Activation

Context

User-Level Thread vs Kernel-Level Thread

Info

Kernel-level threads handle situations like page fault and I/O a lot better because it has direct control over the kernel-level threads. For example, when a user-level thread is waiting for I/O, the kernel will still block the underlying kernel-level threads even though the user-level thread library could technically let another user-level thread run.

User-Level Thread Kernel-Level Thread
Purposes
  • Offers functional parallelism
  • Offers an intuitive way to express parallelism that the application needs
    		•
  • Offers physical parallelism
  • Takes the advantage of multi-core CPU to gain speed up
    		•
    Advantages
  • Less overhead
  • Customizable
  • Tailored to application specific purposes (i.e. specialization)
    		•
  • System integrated
  • Protection from the kernel
  • Hardware parallelism
    		•
    Differences
  • Operations are usually procedure calls
    		•
  • Operations are usually syscalls
    		•

    Example: Java Language Thread Interface

    Java runtime environment will use syscalls to create some kernel-level threads depending on the actual number of cores of the CPU. Java runtime environment then creates a bunch of user-level threads running on top of these kernel-level threads.

    Different approaches:

    • M to N model (Java)
    • M to M model
    • M to 1 model (Python)

    Goal

    • Completely remove the kernel-level scheduler because it is making decisions without information about the running applications.

    Implementation

    Scheduling Decisions

    • Scheduler activation (SA) is very similar to a kernel-level thread, but after making a blocking decision, SA uses up-calls to let the user-level library decide which (thread) to run next.
    • The kernel scheduler is only responsible for resource allocation, decisions are made by the user-level library.

    Context Switch

    When doing context switch for kernel-level threads (for example, a thread is blocked due to I/O operating), the operating system will create another fresh SA which is not associated with any user-level thread. The OS then does an up-call to let the user-level library decide which user-level thread will be associated with this fresh SA. → the user-level application will decide which thread to run next.

    After the I/O completes, the OS will then do an up-call to the user-level applications and let it decide which one to run.

    Takeaway

    My Question

    • How does a context switch for multi-core work for SA?
    Back to top