From: Clifford B Schmidt (cliffsch_at_u.washington.edu)
Date: Mon Jan 26 2004 - 17:17:40 PST
Forwarding from different account since original message hasn't appeared on list.
-----Original Message-----
From: Cliff Schmidt
Sent: Monday, January 26, 2004 3:55 PM
To: hype-csep551-12_at_www.cs.washington.edu
Subject: Cliff Schmidt's review of Scheduler Activations
This paper argues for a better thread model than the existing kernel threads
or user-level threads that were (and are?) the only options available to
developers. The problem with user-level threads is that they don't have
the flexibility to access protected resources such as I/O functions. The
problem with kernel threads is performance. Even when a processor is
switching threads within the same process, kernel threading requires the
cost associated with passing through an extra boundary. Kernel threads
also require a one-size-fits-all solution that means extra overhead for
applications that don't utilize the full flexibility (such as priorities).
The paper explains that the cost of user-level threading is within an
order of magnitude of a procedure call. Kernel-level threading is an
order of magnitude better than context-switching processes, which is an
improvement, but still an order of magnitude worse than user-level
threading. The dilemma is to design a thread package that takes
advantage of the performance of user-level threading model in common
cases that do not require kernel intervention, but provide a means to
allow the kernel to have enough control to handle I/O and processor
reallocation without impacting the overall performance.
The approach that the authors propose is an abstraction of a virtual
multiprocessor. There were a couple times in the discussion that I
wondered whether the processor referred to was virtual or real, but
I think in most cases it was describing how kernels can allocate real
processors that are decoupled from the virtual processors that the
user-level code sees. I've written multithreaded code on a single
processor before, but having never coded for multiple processors, I'm
not completely familiar with the differences.
The mechanism that is described is a "scheduler activation", which
sits between the kernel and the user-level code in an effort to shield
each side from the wrong abstraction of the other. The key division
of responsibilities of the kernel and scheduler activation are
explained in section 3:
- the kernel allocates processors to address spaces
- the thread system has control over which threads run on the allocated
processors
- the kernel notifies the user-level thread system when the number of
processors change or when a user-level thread state changes.
- the thread system notifies the kernel when fewer or more processors
are needed.
Overall, I thought this paper was very easy to read and quite
interesting. I'm actually going to discuss with my group the
possibility of exploring a piece of this in our project to work on
Linux thread scheduling.
This archive was generated by hypermail 2.1.6 : Mon Jan 26 2004 - 17:17:41 PST