Resource Containers and Lottery Scheduling Jonathan Ledlie CS 736
February 23, 2000

Both of these papers are trying to solve a common problem, albeit with
different approaches.  The problem is that applications usually know
what is best for them and could manage their own resources better than
the OS can.  The main reason applications are not given this kind of
control is that the OS retains a better global picture in most
circumstances.  The Lottery scheduler tries to overcome this gap in
understanding between what is best for the whole vs. a subset, by
allocating resources to a subset and then letting that subset manage
itself.  Their extension to Mach provides the mechanism to do this
management but then leave it to applications and their siblings to
determine the policy.  Their mechanism involves currencies which then
give holders greater or lesser chances of winning lotteries for any
given resource.  Besides their initial concept, three other positive
ideas stand out: 1) the separation of currencies into hierarchies, so
that inflation in one area does not affect others and all lotteries
are relative 2) the concept is fairly simple to implement (according
to ex-SGI Brian Forney) 3) even though it might lengthen the time
spent in a context switch, this will result in better choices and
still not make it unduly long.  A problem with their approach is that
applications appear to be able to give themselves tickets  so a
greedy application could harm others. The Resource Container paper
argues for an end to equating processes with chief resource managers,
or resource principals. A resource principal may be
several processes or just one of many threads of a process.  An
extension of this is that resources containers may extend into the
kernel.  This returns to our original point on applications knowing
what is best for them, in that they may need to interact more directly
with the kernel to do what is best.  Their idea is also valuable
methodologically because they are taking a specific problem, HTTP
server management, and providing solutions for it  not general
purpose ones.  Our main difficulty with the paper was that they could
not show their idea was clearly better and, like LFS, this will
probably result in its lack of common adoption.