CS 736 Reviews - Spring 2016

Summary
The paper presents an efficient scheduler where the relative execution time of the process needs to be controlled by using the concepts of randomness and tickets. The paper also shows how the mechanism can extended to manage different resources such as locks, Resource allocation.
Problem
When there are scarce resources they must be multiplexed to service requests of different importance. Users/ Applications require support for specifying the relative computation rates. The existing mechanism rely on priority and Doesn’t provide encapsulation for large software systems.
The paper presents an efficient proportional share scheduling algorithm.
Contributions
The main contribution of the paper is simple and efficient Proportional Share scheduling using the concept of a]Randomness : To select the process (Randomness achieved using park-miller pseudo-random number generator using 10 RISC instructions)b]Tickets which express the resource rights. Starvation doesn’t exist as any client with ticket will eventually win a lottery
Other Important concepts are:
Ticket Currencies: Unique currency is used to denominate tickets within each trust boundary. This ensures inflation of ticket is restrained within the boundary providing insulation. Exchange rate is used to ensure its value in base currency is conserved.
Ticket transfer : Allowing tickets to be transferred from one client to another when not in use, which is helpful in RPC,.Hence solves the problem of Priority Inversion .
Ticket Inflation and Deflation to adjust resource allocation without explicit communication between clients
Compensation tickets:Using the concept of compensation ticket ensuring a client receives its share of the processor when it uses only a fraction of allocated resource.
Evaluation
The Paper shows good evaluation. The paper presents the evaluation of fairness in many scenarios where using the randomness the proportional sharing was very close to what was expected Figure 6,7. An experiment shows that fairness is properly achieved over time Figure 5.The author also evaluates when the proportional sharing was dynamically changed and it graph shows very good results Figure 8.An experiment showing where a process is introduced in-between the execution of other process, proportional sharing is still achieved efficiently as per graph Figure 9.The Section 6 presents results when Lottery Scheduling was used for mutex for proportional sharing for 2 groups and results were waiting time 1:2:.11 and acquisition ratio is 1.80: 1 when expected sharing was 2:1.
Overall i Feel that the the Author has evaluated the presented concepts well and good performance was achieved.Also showing that it didn’t add much overhead to system when compared with existing time sharing scheduler of Mac OS as mentioned in Section 5.6.
The only missing evaluation which is very important was comparing Lottery Scheduler performance with other schedulers present at that time.
Another missing evaluation as whether proportional sharing with randomness was achieved when there 100s of process , the paper only presents evaluation when there are small number of processes.
Confusion
Can you please elaborate the concept of funding .

1. Summary
This paper introduces a probabilistic proportional share scheduling algorithm that aims to optimize the fairness metric using lottery tickets as opposed to the usual scheduling metrics like response time and turnaround time. The concept can be generalized to any resource management problem where the number of tickets a process holds represents the process’s share of the system resource.

2. Problem
There are various desirable attributes from a scheduling algorithm. A scheduling algorithm must be able to accommodate processes of varying priority while the processes can be CPU bound or require interactive response. Priority based scheduling algorithms provide no support for encapsulation and modularity and rely on ad-hoc assignment of priorities. Decay-usage scheduling and multilevel feedback queues are complex and require tuning of various parameters. Moreover, multilevel feedback queues cannot accommodate processes with varying priority. Existing fair share schedulers have high overhead and hence are not efficient for interactive systems that require rapid and dynamic control over scheduling.

3. Contributions
i) The main contribution of the paper is a novel probabilistic proportional share scheduling algorithm that can be generalized for most resource management problems. The lottery scheduling algorithm aims to provide fairness in terms of not just turnaround times but also the response times which is a key differentiating factor from existing fair share schedulers. The average response and turnaround times of any two processes will be proportional to the relative shares they are allocated. The concept is simple: A process holds a number of tickets that is reflective of its share of the CPU. On every timer interrupt, a lottery is held and a winning ticket is drawn and the process with the winning ticket gets the timeslice. ii) Lottery tickets are relative and the share varies dynamically with the active processes contending for the resource but at the same time tickets also insulate varying load within independent modules and hence provide modular resource management. iii) The scheduling mechanism is lightweight and involves only generating a random number and traversing a data structure which can be optimally done in O(lgn) operations where n is the number of active processes. iv) Currencies are used to maintain a list of all tickets that back the currency and a separate list of issued tickets, and can be used to encapsulate different modules. Ticket transfers can be used to transfer tickets temporarily and a novel mechanism of compensation can be used to compensate for I/O bound tasks.

4. Evaluation
The authors measure the fairness of the scheduler for two processes with varying allocations and found the scheduler to be fair for most cases. The disadvantage is that the scheduler is fair only when the running processes are long. A measurement showing how the scheduler performs for short processes that execute for a shorter period than 60 seconds would have been interesting. An evaluation that shows how the fairness varies with various length of jobs for varying shares as opposed to fixing the length to 60 seconds would have brought out interesting result with respect to how more skewed proportions require longer running processes for the scheduler to be fair. The measurements show response times and throughput to be proportional to the share for various workloads. It would have been interesting to see how the scheduler performed in terms of overall response time or throughput as opposed to existing schedulers. Does this scheduling algorithm brings up the overall turnaround time or response time? An evaluation with a workload that is both CPU and I/O bound could have been interesting.

5. Confusion
How can be a lottery based scheduling scheme applied for disk bandwidth scheduling as claimed by the paper? Is fairness the right metric for disk scheduling as opposed to optimizing for seek time? Who deals with the ticket assignment? The problem of ad-hoc assignment of priorities, a problem with priority based schedulers is still unsolved if users assign tickets.

1.Summary
This paper proposes lottery scheduling - a novel randomized resource allocation mechanism that provides efficient and responsive control over the relative execution rates of computations. The proposed scheduling mechanism offers proportional-share resource management and support for modular resource management.

2.Problem
Scheduling computations with “fairness” is a complex and challenging problem. Conventional scheduling schemes have been limited in one way or the other with a few of them offering flexible and responsive control over service rates. Most of them that use the notion of “priority” with dynamic adjustments are ad-hoc, complex and do not meet the overall goal completely. Approaches such as “fair share” schedulers and “microeconomic” schedulers that address some of those limitations have very high overheads and assumptions that limit them to relatively coarse control over long-running computations.

3.Contributions
The overall contribution of this paper is the randomized resource allocation mechanism - lottery scheduling that provides probabilistic fairness. Even more important contribution is the simplicity of this approach. It provides abstraction, uniformity and modularity to the resource allocation mechanism that makes it very easy to reason and express.
Some of the key contributions are:
* Resource rights represented as lottery tickets that allocates resources to competing clients in proportion to the number of tickets that they hold
* Lottery mechanism that guarantees any client with non-zero number of ticket to *eventually* win a lottery thereby eliminating the conventional problem of starvation
* Lottery tickets in modular resource management with ticket transfers, ticket inflation, ticket currencies, and compensation tickets

4.Evaluation
Overall the authors evaluate their system with broad set of experiments verifying the effectiveness of lottery scheduler and lottery-based resource management.
The authors implemented a prototype lottery scheduler by modifying the Mach 3.0 microkernel on a 25MHz MIPS-based DECStation 5000/125 and conducted few experiment with applications including Dhrystone benchmark, Monte-carlo numerical integration program, a multithreaded client-server application and competing MPEG video viewers.
The experiments used address their major claims about the approach: fairness, flexible control, load insulation and low overhead. The diverse set of applications and experiments illustrate the effectiveness of this system.
However, the authors do not show how this system compares with other systems without the lottery schedule in terms of performance and overheads. Also, the 100 millisecond quantum used in these experiments seems like cherry-picking.

5.Confusion
What heuristics does it use to determine whether a program is CPU-bound or I/O intensive or interactive? The paper does not mention this. Can users express it?
Also the mechanism of backing and “funding” a currency with tickets is not clear to me.

1. Summary
This paper presents the idea and implementation of lottery scheduling, a randomized mechanism that allows responsive control over executions. It significantly reduces overheads via probabilistic proportional sharing based resource management and provides support for modular resource management. It is generic enough to be used to manage diverse resources such as I/O b/w, memory, access to locks etc. It provides higher flexibility than standard fair shares by introducing of ticket transfers/compensation, currency, inflation etc.

2. Problem
Most existing mechanisms at that time did not provide flexible and responsive control over service rates. Either they simply relied on some fixed priority values which gave absolute precedence between tasks but resulted in very crude scheduling or were overly complicated fair share mechanisms that required periodic usage updates, dynamic priority adjustments etc.

3. Contributions
The novelty in the paper is the idea of probabilistic fairness. Rather than overly complicating the mechanism to employ exact fair share between threads, the authors implement a lightweight probabilistic fair share mechanism which converges to fair share over long periods (i.e over a large set of lottery allocations) - thus suiting long running threads.

The authors implement the idea of a ticket which provides more substance to the idea of priority. Earlier methods generally implemented priority as simply one process over the other, while this paper converted this into some actual number scheme which eased actual allocation and implementation.

Some novelty beyond the general mechanism is achieved in the paper as they implement ideas such as ticket transfers - wherein blocked threads can transfer their tickets to a dependent low priority thread preventing priority inversion problems, ticket inflation to boost up priorities among mutually trusting clients/threads, ticket currency to ease user level management while keeping the user priorities levels the same, and compensation tickets to guarantee fairness beyond just giving an opportunity for all tasks - actually ensuring that the tasks get time to execute in proportion to their shares.

4. Evaluation
They implement the lottery scheduler atop the Mach 3.0 microkernel. Accuracy of the lottery scheduler in ensuring fairness is tested on 2 tasks running the Dhrystone benchmark. Next, the concept of ticket inflation is validated running the Monte Carlo. The ability to transfer tickets from one thread to another to hasten the execution of the server is shown with three database clients and a server with no tickets on its own and the clients transferring tickets to the server to control its priorities.

Ticket inflation is evaluated atop multimedia applications while load insulation shows how priorities with a user space are abstracted away from priorities between user spaces themselves. Introducing new threads within a userspace only adjusts the internal priorities, while a new client only adjusts the overall user priorities.

The main problem in evaluation is that there is no clear comparison with any existing mechanism which shows how much better they were compared to the state-of-art allocation policies in that era. This was a problem with the motivation of the paper in general as well - the paper clearly highlights issues which need to be addressed but doesn’t provide enough details in the introduction and motivation as to where prior schemes were exactly lacking. More details on this is provided at the end in related work but should have probably been highlighted more clearly to start with.

5. Confusion
The concepts behind some of the competing mechanism are briefly mentioned in the paper but their highlights and lowlights are not very clear.

How is the allocation of priorities between clients/threads managed? This paper talks at length about how the ticket values are used, but how are they assigned and modified? What is being monitored to keep updating these priorities?

How important is system throughput? In some cases, ensuring fairness causes the system to take a performance hit - eg. in the compensation tickets case, the number of context switches could increase significantly reducing the total useful work on the system - is this a factor which is balanced with fairness?

The paper talks about this mechanism being abstract, relative and uniform. While ticket values do better the ‘relative’ part, how is this any more abstract or uniform than any other scheduling policy?

1. Summary
This paper presents the idea and implementation of a randomized resource allocation mechanism lottery scheduling, which provides efficient, flexible, fair and responsive control over relative execution rates of computations desirable in databases & multimedia-based applications.

2. Problem
Scheduling computations in a multi-threaded system is a complex problem, with the policy chosen to multiplex resources having a big impact on throughput and response time of the application. For providing accurate control over quality of service to the users, support for specifying relative computation rates within applications is needed. The popular priority based schemes are poorly understood and do not provide direct dynamic control over regulating computations. Existing fair share schedulers provide control over computation rates only at a very coarser level.

3. Contributions
Resource rights are represented by lottery tickets in the scheme designed by the authors, with the resource being granted to client with the winning ticket.The client would receive the resource share proportional to its share of tickets. Scheduling by lottery mechanism is guaranteed to be probabilistically fair and problem of starvation does not arise in this scheme. Lottery scheduling is extremely responsive in the way that any changes in relative ticket allocations get reflected immediately.

Lottery scheduling mechanism has been designed for modular resource management with various implementation techniques. Ticket transfers are can be used in any situation when a client gets blocked due to some dependency, solving the priority inversion problem in existing systems. Inflation provides mutually trusting clients to adjust resource allocation without communication. The currency abstraction helps with flexible naming, sharing and protection of resource rights. Compensation tickets inflates a client share when it only uses a fraction of its allocated quantum. Lottery scheduling can be generalized to manage various resources like I/O bandwidth, memory and access to locks.

4. Evaluation
The authors have implemented a prototype lottery scheduler on Mach microkernel supporting user level ticket allocation. The authors describe experiment for demonstrating fairness and flexible control by running Dhrystone and Monte Carlo simulations. In the latter case, experiments started initially with high error rate have a much higher rate of computation as desired. The authors evaluate the performance of the mechanism on client-server and multimedia to demonstrate that the rates of computation match the allocation desired. Results from load insulation are presenting which demonstrate how inflation is contained modularly. On comparing system overhead with other schedulers, a comparable trend was observed for the Dhrystone benchmarks although running comparisons on a diverse set of benchmarks could have illustrated the comparison better.

5. Confusion
How are lottery schedulers different from fair share scheduler? Is lottery scheduling used in operating systems today?

1. Summary
This paper discusses a novel, randomized scheduling idea based on the concept of lotteries. The tickets assigned can be used for diverse resources -memory, I/O bandwidth, and access to locks. It is illustrated how in a processor scheduling system, the number of tickets owned is proportional to the throughput attainable and inversely proportional to the response time. Authors built a proof-of-concept on top of Mach3.0 kernel on a MIPS-based DECstation.

2. Problem
The traditional schedulers had priority schemes having ad-hoc priority assignments and dynamic priority adjustments. Schemes that are popularly deployed on multiple operating systems such as decay-usage scheduling are not properly understood. With the Fair Share schedulers, only coarse control on long-running computations can be achieved. So the fairness is possible only in the long-term. But interactive systems need rapid, dynamic control over scheduling at a time scale of milliseconds to seconds in database, networks and media-based applications. Starvation is another problem in scheduling policies and that has been addressed by lottery scheduler.

3. Contributions
Basic idea involves two abstractions: a currency and a lottery ticket. Currencies form an acyclic graph rooted at a single node for the base currency. Lottery scheduling is probabilistically fair, which implies that it can be formally proved that they do not cause the conventional problem of starvation. The tickets can be transferred from any blocked thread back to the server or a thread that will actively use it and that solves the priority inversion problem. The tickets are claimed to be abstract, relative and uniform even across heterogeneous system resources. It allows the users to create new tickets and adopts the idea of inflation and deflation amongst mutually trusting clients. Compensation tickets favor I/O bound and interactive threads to get their fair share of CPU time.

4. Evaluations
Probabilistic approach brings in interesting benefits: under the assumption of uniform distribution, law of large numbers guarantees convergence on expected ratios. The random number generator and the lottery scheduler need to be fast in order to ensure coherence in the system. I especially liked the probability-based schedule policy, such as a binomial distribution since that ensures fairness. The paper does not explain how PRNG is seeded with fixed seed material the algorithm is deterministic. Monte-Carlo simulation makes for another showcase for lottery scheduling: by deflating the number of tickets available, long-running tasks receive less and less CPU time to allow for rapid initial convergence from new simulations. Also, ticket inflation requires cooperation and planning between processes competing for resources, which complicates programming model. However, in my opinion this approach does not provide the responsiveness for a mixed interactive and CPU-bound workload that is offered by FreeBSD's OS and also lottery scheduling ignored kernel priorities that leads to higher lock contention.

5. Questions
How does this ideology scale to distributed multi-core systems and managing resources across the network. Is there a central ticket allocator that must be maintained?

1. Summary
This paper describes a technique in which threads are scheduled using a random lottery, based upon weights that can be set before the thread runs or while it is running. The authors implement this on a Mach microkernel and evaluate it on microbenchmarks.

2. Problem
Most thread schedulers rely upon priorities to schedule threads. However, these do not provide good modularity, because the running time for any thread depends on the priorities of all other threads. (In addition, priorities are used infrequently.) While other thread scheduling mechanisms had been designed, they had high overhead or required much trial and error in order to work well.

3. Contributions
This paper describes lottery scheduling, in which threads are scheduled probabilistically. Each thread is assigned "tickets", which serve as weights on the probability that it will be called. Each time the scheduler chooses a thread to run, the probability that a particular client will be run follows a binomial distribution. How long before each thread will run follows a geometric distribution. The randomized nature of the scheduler prevents starvation.

The paper presents multiple tricks for improvement the scheduling. First, when a thread blocks on a call to another thread, it can transfer its tickets directly to the called thread, providing greater efficiency. Also, a group of threads can use a different "thread currency", which allows them to express their weight relative to each other. The group collectively holds tickets that determine its members' weight relative to all other threads. Finally, if a thread does not use its full allocated time, it can be granted extra tickets so that it actually receives the resource time that its original tickets indicate.

The paper also considers using this technique to manage other resources than processor time. First, they extend a threads package with a lottery-based scheduling mechanism, and evaluate it on a synthetic multithreaded application. They also consider adapting their technique to manage memory, using an inverse-lottery mechanism in which a page would be evicted if it had the lowest number of tickets. Going off that, they point out that the lottery mechanism can represent different resources uniformly, which would allow systems to quantitatively compute tradeoffs between the resources.

4. Evaluation

The authors evaluate their implementation in various ways. They evaluate its fairness using a benchmark suite, and demonstrate that thread running times are always very near the proportion specified using the lottery tickets, although the times have higher variance for large ratios. They evaluate the flexibility of their tool using a Monte-Carlo numerical integration program. They configure each Monte-Carlo experiment to claim fewer tickets as its error decreases. When they run three Monte-Carlo tasks simultaneously, the number of trials each is able to run in a given time converges nicely.

They test the transfer of tickets from clients to the server by implementing a text search similar to a database. This test demonstrates that the processing rates for the queries closely follows the ticket allocations of the clients, despite that the work is done by the server, with a standard deviation of 7%. They also test multiple video players running simultaneously, showing that they run in their allocated times. They test the flexibilitity of their system by changing the ticket allocations of the video players while they are running, where within 100 seconds the allocation proportions have changed. Finally, they compared their efficiency to that of the base system, Mach, and find that there should be no noticeable difference.

This evaluation seems fitting, but it would have been useful to have more real applications. While the video players were useful, the other real application, the Monte-Carlo program, did not seem to have clear results.

5. Confusion
While I think I understand them now, I would appreciate going through ticket currencies and compensation tickets in class.

Summary:
The paper introduces a randomized resource allocation algorithm called Lottery Scheduling, which provides a flexible resource sharing model which caters to the changing resource demands of the individual tasks. It provides a responsive control over the relative execution rates of individual tasks using proportional sharing and modular resource management techniques.

Problem:
Current scheduling policies at that point in time were based on dynamically changing priorities and do not provide flexible, responsive control over execution rates. Widely used fair share schedulers provide coarse grained control due to their overhead, thus impacting interactive applications. Thus, lottery scheduling aims to provide fine grained control of system resources by varying the proportional share on the resources with changing priorities.

Contribution:
The paper describes the description and implementation of the mechanisms used to implement this proportional share resource management technique. Lottery tickets provide an abstraction for resource rights which are assigned to clients. It proves that scheduling is probabilistically fair based on the fact that the expected allocation is proportional to the number of tickets assigned. There is no starvation issue since very client holds at least one ticket and eventually every client gets the resource. It provides a modular resource management technique using tickets through ticket transfers, ticket inflation, currencies and compensation tickets, since tickets are just objects that can be easily manipulated and transferred. The concept of currencies is what makes the model attractive since it allows a client to decide the relative importance of each subtask of its task without affecting the other running clients. It also explains how this approach could also be used in resolving lock contention better than existing policies.

Evaluation:
The evaluation was performed by modifying the Mach 3.0 microkernel on a MIPS based DEC station. First, the paper evaluates fairness where the execution rates are measured proportional to ticket allocation ratios of two running tasks with different allocations using compute bound Dhrystone benchmarks. Second, to measure the effectiveness of ticket inflation Monte Carlo algorithm is executed to show fine grained and dynamic process scheduling capabilities, where the resource shares are error rates which decrease with time. Third, a client server system is used to evaluate ticket transfers and no tickets are assigned to the server directly. The overhead of the lottery scheduler and the Native Mach has been evaluated.

The paper mentions about the shortcomings of their current implementation but does not provide a details analysis and have just mentioned about potential optimizations without any guarantees. Since this is a new scheduling technique, a case in point comparison of response time and turnaround time against all the other existing schedulers on a range of workloads could have also been provided, but I guess since their current implementation was not efficient they might have refrained from doing the same. And, the paper does not measure the effectiveness of the system in a setting where the number of clients/processes is very large with a large number of threads which very dynamically changing priorities and proportional shares to prove the system is scalable with minimal overheads (memory and compute). But overall the evaluation section of this paper was nice to read.

Doubts:
Are these concepts being used in modern schedulers? Why fair share scheduler is more commonly used though this looks promising?

Summary:
Lottery scheduling provides efficient responsive control over the relative execution rates of computations. Such control is beyond the capabilities of conventional schedulers and is desirable in systems that service requests of varying importance such as data bases, media based application and networks. It also enables modular resource management by enabling concurrent modules to insulate their resource allocation policies from one another. It can be generalized to manage many diverse resources, such as I/O bandwidth, memory and access to locks.

Problem:
Scheduling computations in multithreaded systems is a complex problem. Scarce resources must be multiplexed to service requests of varying importance and the policy chosen to manage this multiplexing can have an enormous impact on throughput and response time. Existing dynamic priority adjustment schemes were adhoc whereas fair share schedulers had coarse control. Lottery scheduling implements proportional share resource management and provides excellent support for modular resource management.

Contribution:
The whole idea of allocating a proportional share of tickets to each client and then randomly select a winning ticket and select a winning ticket is a contribution to the area of operating system schedulers. Some of the key features are :
i) Lottery Scheduling is starvation free - every ticket holder will get scheduled
ii) It is probabilistically fair
iii) Ticket transfer: allows transfer of ticket from one client to another. This helps to solve priority inversion. When a client waits for a reply it can transfer its tickets to the server
iv) Ticket inflation: Lets users to create their own money, but allowed only among mutually trusting clients.
v) Ticket currencies: favor one thread over other without impacting other set of threads. Implements modularity.
vi) Compensation tickets: address the imbalance created with I/O operations using only a fraction of their CPU time.

Evaluation:
This scheduler was evaluated on a MIPS-based DEC station running Mach 3 microkernel.
The paper does not deal with the problem of assigning ticket numbers to each client in a real scenario. For evaluation, they allocate tickets to clients in a specific ratio and then prove the response times and throughput to be proportional to the allocation ratio. The concepts of ticket transfer, modularity using ticket currencies and flexible control of resource allocation is clearly conveyed with these examples and graphs. In all cases the lottery scheduling is seen to be working as expected. I feel the system has been tested for very small set of workloads, the idea seems to be working, but it would be good to evaluate it for a set of >10 application users logged in, with a mix of compute bound, I/O bound and interactive workload. Also, system overheads have not been discussed in detail, like break up of how much time does generating a random number and selecting a client takes. The overhead is explained in terms of 2.7% fewer iterations with lottery scheduling when set of 3 tasks are run concurrently. And, with 8 tasks it was observed to 0.8% slower. This difference is unclear to me and I feel needs more detailed explanation.

Summary : The authors in this paper present lottery scheduling, a dynamic resource allocation mechanism based on random numbers. Lottery scheduling is presented to be responsive to share changes. It gives rise to modular programming by the isolation of allocation policies by using currency abstraction. It also can be generalized to handle I/O bandwidth, memory, and access to locks. The authors state that the overhead observed is comparable to Mach 3.0 and authors evaluate the model for its goals by conducting a number of experiments and analyzing the empirical data.

Problem : Given a multi-threaded system, scheduling scarce resources is a complex task. Schedulers existent at that time lacked the throughput and response time to multiplex resources in interactive systems. Even though there existed priorities, the assignment of priorities and dynamic adjustment of these priorities were ad-hoc. Schedulers were mostly coarse grained for long-running computations as they had overheads and were based on assumptions. Lottery scheduling aimed at addressing the above shortcomings in schedulers.

Contributions : a] Client gains controls over a resource by winning the lottery where holding a lottery ensures allocation of resource. b] Lottery scheduling is probabilistically fair (avoids starvation), and the actual allocations are not an exact match of expected proportions as lottery scheduling is a randomized algorithm. c] Changes on ticket allocations are reflected in next allocation decision, making this responsive in interactive environments. d] Resource management policies are insulated in independent modules by the notion of tickets and currencies. e] Clients can increase their resource rights by creating more lottery tickets, known as ticket inflation. f] Currency determines the ticket denominations in a trusted boundary. Exchange rate between local currency and base currency is kept constant and this ensures that the effects of inflation are locally contained. g] Resources are allocated in granularity of quantum. A fraction f of the allocated resource quantum is the amount of resource a client consumes. h] Micro-kernels present a simple lottery scheduling interface that has operations to support creation and deletion of tickets and currencies, fund and unfound currencies and to calculate the value of tickets and currencies in terms of base units. i]A blocked client transferred its resource rights to the server it is waiting on.

Evaluation : The authors implemented a prototype of lottery scheduler for the Mach 3.0 microkernel. Fairness can be achieved over 8 second intervals if he scheduling quantum is 100 milliseconds, if this was changed to 10 milliseconds, fairness was achieved over alternate intervals. The authors also in a setup where 3 clients with a ticket allocation proportion of 8:3:1 compete for a service from a multithreaded database server. Throughput and overhead with a standard deviation of 7% was found to match the allocation and average response time. Authors also evaluate lottery scheduling over Dhrystone benchmark and demonstrate empirical evidence to show that lottery scheduling executed fewer instructions. It also exhibited speedup in computation in multithreaded database servers. We can infer that authors were successful in providing a flexible and responsive resource management scheme over a wide range of applications and heterogeneous resources, the overhead for the optimized version was similar to that of a standard Mach, giving hope that an optimized version would decrease this overhead. Having carried out extensive evaluation the authors could have evaluated more in comparing lottery schedulers with conventional ones not only on the basis of overhead but various other aspects such as security due to tickets and currencies, extra memory required to maintain the tickets and currencies, and a profiling would help users understand better as to which design aspect/s of lottery scheduling is contributing to the overhead.

Confusion : i] How does the initial assignment of tickets to processes happen? ii] The paper does not mention how address space is shared between processes that possess tickets and currencies to gain resources by lottery.

1. Summary Through a hierarchical currency model backed by "tickets", which are used to implement a per-quantum lottery, Lottery Scheduling provides a dynamically adjustable probabilistic mechanism for allocating proportional shares of CPU time to processes.
2. Problem
Designing a scheduler policy for a general purpose operating system is challenging; workload demands can vary greatly, emphasizing different balances between latency, throughput, and job prioritization. Many existing policies, such as e.g. priority based schedule policies are constructed in an ad-hoc manner and are often difficult to mathematically analyze in a rigorous fashion. Additionally, when processes interact either as peers or hierarchically, the ability for cooperating processes to transfer access to CPU time, or to regulate the processor time allocated to subsidiary process are useful abilities to give to application developers who want to adjust their programs' CPU usage. However, naive interfaces for tuning scheduler policies may allow processes to violate isolation policies and game the scheduler.

3. Contributions
The core of the scheduling policy is a per-time-slice lottery; in the most basic conception of lottery scheduling, there are a fixed number of lottery tickets available in the system, and each process is allocated some fraction of the tickets. When a scheduling decision needs to be made, the scheduler selects a random ticket, and schedules the process which holds the ticket. In the limit, the proportion of processor time used by a process will converge to the fraction of system-wide tickets held by the process, where the rate of convergence is governed by the time slice quantum. When the amount of tickets available system-wide is held at a fixed amount, cooperating processes can pass tickets between each other to adjust their relative execution rates - for example, a process making a long-running synchronous IPC call to a server can choose to allocate all of its tickets to a server, reducing the expected wait. The laws of probability ensure that the effects of these trades are isolated to the processes participating in the exchange; as long as a process holds onto its tickets, it's expected CPU access will not change (excluding OS induced inflation or deflation). To ensure that I/O intensive processes are treated fairly, a process that yields the CPU is issued a compensation tickets proportional to the inverse of the fraction of the time slice used.

In a design choice reminiscent of Nucleus, processes which spawn children can create hierarchies of currencies, each of which is backed by by some lower-level currency, back down to the basic lottery tickets. Thus, parent processes have explicit and fine-grained control over the prioritization of child processes. The authors show that this basic model can be used to multiplex other forms of resource access. Memory can be managed by a reverse lottery can be held, in which a loser has a page evicted. Also, scheduler tickets can be allocated to the holder of a mutex in such a way that priority inversion is eliminated.

4. Evaluation
The authors evaluate the fairness of the policy in several experiments; they show that while CPU allocations exhibit variance on the timescale of several seconds, the average scheduling proportions stay close to the expected values over longer time scales. They also show that the reallocation of load between two processes does not perturb the allocation of a third process in any meaningful fashion, and that average frame rate for MPEG playbacks are distributed in the expected manner. I was disappointed that the majority of the time slicing metrics were focused on averages, particularly after earlier discussion of variance and rate of convergence; the emphasis on averages condenses time slicing, a two-dimensional process, into a single data point. Empirical studies of search engine usage have shown that users are very sensitive to worst-case performance; even a second of delay is enough to make some users leave. Given this, I would be interested in seeing some empirical evaluation of how the choice of scheduler quantum affects the convergence of the policy.

5. Confusion
I'm a bit rusty on statistics, so a review of variance would be appreciated.

Summary 
This paper presents a new randomized resource allocation mechanism known as lottery scheduling that determines resource allocation by conducting a lottery among competing clients- with each client having varying number of lottery tickets in proportion to its share. This not only gives fine-grained control over relative computation rates, but by introducing an abstraction of currency, modular resource management can also be efficiently supported.

Problem           
The paper talks about the problems associated with contemporary conventional schedulers, which do not guarantee efficient responsive fine-grained control over resource allocation. For example, the mechanisms employed by priority-based schedulers are too often ad-hoc and crude, as the resource rights do not vary smoothly with priorities. On the other hand, fair share and microeconomic schedulers fail to provide rapid dynamic control over scheduling at microsecond level, due to their complexity and high overhead. This paper aims to solve these problems, while at the same time, facilitating modular resource management.

Contributions
According to me, following are the novel contributions of this paper:
(1) A novel randomized resource allocation mechanism that is conceptually simple and can be easily implemented in current operating systems to provide efficient control over resource consumption,
(2) the concept of lottery tickets, as a relative uniform abstraction to quantify resource rights even for heterogeneous resources,
(3) the mechanism of conducting lotteries to determine the winner in a probabilistically fair way, while at the same time avoiding starvation,
(4) the concept of ticket currencies and exchange rates to define logical trust boundaries, which enables modular resource management,
(5) ticket inflation and ticket transfers as lightweight priority inversion mechanisms to allow responsive dynamic control over resources,
(6) use of compensation tickets to guarantee fairness among competing clients, some of which may not consume their entire quantum at times,
(7) finally the authors have also shown that their lottery scheduling mechanisms are generic enough to manage diverse kinds of resources like processor time, lock access, I/O bandwidth, memory etc. 

Evaluation
The authors implemented their lottery scheduling prototype for a Mach 3.0 microkernel on a 25MHz MIPS-based DECStation 5000/125 with a scheduling quantum of 100 ms. They measured the fairness of their proposed scheduler by having two tasks run Dhrystone benchmark with a pre-defined resource allocation ratio. The lottery scheduler was able to fairly achieve the same level of iteration ratio in proportion to the allocation ratio in both shorter and longer intervals of time. In an another experiment, the authors demonstrated the precise dynamic control over resources achieved with their proposed scheduler by controlling the execution rate of three Monte Carlo integrations according to their varying relative error rates.
The concept of ticket transfers to achieve priority inversion was put to test using a client-server multi-threaded computation, in which three different clients maintained their response and execution time for their queries in proportion to their ticket allocation. Using a synthetic workload consisting of two currencies, where one was inflated and other was not, the authors showed how modular resource management could be achieved when the effects of inflation in one currency are insulted from the other. Finally, by comparing the performance of their own scheduler with the Mach’s scheduler with time sharing policy, the authors claimed that their scheduler could achieve much of the benefits without much system overhead.
Overall, I felt it was a nice evaluation, where the authors have tried to present evaluation for almost everything that they have proposed. However, the authors have compared the overhead of their lottery scheduler with a simple time sharing round-robin scheduler in Mach Kernel, which may be a little biased comparison. This is because lottery schedulers tend to benefit from the improved caching and TLB effects when the same process often wins multiple lotteries consecutively in a row, whereas round-robin schedulers always suffer from bad cache and TLB performance. It would have been more insightful, if the authors had presented the comparison of the lottery scheduler with microeconomic or fair share schedulers. 

Confusion
What does it exactly mean to “fund” and “un-fund” a currency and do inactive threads lead to un-funding of a currency?

1. Summary
This paper describes lottery scheduling, a randomized approach towards scheduling that is flexible, fair and fast. The authors implemented their design on a Mach 3.0 microkernel and evaluated it along several dimensions.

2. Problem
Traditional schedulers typically provide coarse control over long running computations, are inflexible, hard to control, lack dynamic behaviour and had a lot of overhead to provide these facilities. They also suffered from problems like priority inversion. The authors address this issue with a solution that is flexible and adaptive to current conditions while requiring minimal overhead to perform the scheduling.

3. Contributions
- Lottery scheduling is a flexible technique which can be generalized to manage diverse resources such as memory, I/O bandwidth and access to locks.
- This scheduler provides probabilistic fairness as resource allocation is directly proportional to the number of tickets held.
- The priority inversion problem is addressed by allowing explicit transfer of tickets from one client to another. Ticket inflation and deflation can be used to dynamically adjust resource allocation. Compensation tickets help provide mechanisms that provide an advantage to tasks that yield the cpu before consuming their entire allocation quantum and help start them quickly during the next decision phase.
- Ticket currencies provide protection of resource rights, flexible naming and sharing.
- Changes to relative ticket allocations are observed in the next decision phase which provides responsive control over resources.

4. Evaluation
The authors evaluate this scheduler by implementing a prototype on the Mach 3.0 microkernel.
- To measure fairness, they employ two Dhrystone benchmarking tasks. The results indicate that execution rates are directly proportional to the number of tickets held by each task.
- The Monte-Carlo algorithm is employed to quantify ticket inflation and here resource shares are determined by error rates.
- Ticket transfers are evaluated in a client-server setting wherein the client transfers its tickets to the server for running queries.
- MPEG video viewers were employed to measure and observe the change in relative resource allocation ratios.
- The authors also evaluated their scheduler against the Mach scheduler and observed that their scheduler executed fewer (2.7%) iterations.

The authors could have performed additional evaluations to measure the cost of lotteries and ticket transfers.

5. Confusion
How is the initial ticket allocation decided ??
Why is this scheduler not implemented in the Linux Kernel ??

1. Summary
The paper discusses lottery scheduling technique which efficiently manages execution rates of computations, offers modular resource management and currency abstraction, without incurring significant operational latency over existing techniques. This method can be extended to other resource sharing problems like memory, I/O and lock synchronization.

2. Problems
Existing schedulers have their fare share of problems when it comes to addressing fairness, ability to respond to change in priorities and do not provide encapsulation and modularity. This affects in the ability of the scheduler to have fine grained control over the execution of applications. Some of the scheduler like fair share and microeconomic scheduler which address these problems however add significant overheads that limits them from controlling long running application.

3. Contribution
The paper’s main contribution is the lottery scheduling technique which is realized using the following entities:
(i) Lottery tickets: These are the basic abstraction the resource rights for applications for execution. Any process that holds the lottery ticket chosen for the iteration gets the resource. Tickets are chosen randomly from a uniform distribution. Thus any process with a non-zero ticket gets a chance no execute( no starvation) and a process that holds more tickets has greater probability of scheduling at the earliest (better response) and more share of the resource.

(ii) Ticket currency : The notion of a ticket currency enables the scheduler to adjust the value based on the number of backers and maintain fair share for a process even if some of the threads are blocked out. This also increases the system efficiency. Ticket inflation helps in tackling the processes which could try to monopolize the resource by creating tickets. The inflation brings down the value of the ticket and hence ensures fairness. Currency also helps in compensating the processes which relinquishes control earlier than the scheduled time.

The methodology enables transfer of tickets between processes which helps in cases like RPC call, where server now gets additional resource time to process client (uses client’s ticket). This can also employed in reducing mutex wait times.

4. Evaluation
The authors have implemented the technique by modifying the Mach 3.0 microkernel and used mach_msg system for ticket transfers. The authors have presented an extensive evaluation. The paper has evaluated the technique in terms of fairness, accuracy of allocation ratio, responsiveness of the scheduler, throughput and ability to insulate the load between two processes. They also compare their implementation with the scheduler of the native mach kernel and show that it does not add significant additional overhead to the system. One feature that the paper has missed to evaluate in the ticket compensation feature. There is no data to back their claim of how efficient the compensation technique is. Also, the paper does not talk about scheduler’s performance under real world conditions. Having 5 clients querying the database simultaneously do not give a clear picture on how it would handle many processes running parallely. Also, for attributes like response and execution time(using RPC type client-server interactions), the authors do not compare against existing technique to show how much their work has improved upon existing techniques.

5.Confusions
What further improvements have been done to this technique? What changes are incorporated into this methodology when it is implemented in a multi-core system?

1. Summary
This paper describes Lottery Scheduling, a randomized scheduler mechanism which does proportional-share resource management through distribution of tickets. Lottery scheduling is expected to provide responsive control over the relative execution rates of different processes while maintaining great flexibility.
2. Problem
Generally all existing scheduler mechanisms suffer from a trade-off between flexibility and complexity: on the one hand, schedulers that use a simple notion of priority lacks the capability of providing flexible scheduling schemes in large systems of long-running applications; on the other hand, schedulers that do provide better flexibility such as fair share schedulers and microeconomic schedulers make certain assumptions and overheads limit their usage and granularity of control.
3. Contributions
The Lottery Scheduling aims to provide good modularity and find-grained control over the shares of different processes, while maintaining some level of efficiency and simplicity.
Lottery Scheduling uses the abstraction of ticket as a base unit of resource share. Ticket as an abstraction of resource right can adapt to different allocation policies in independent modules, and can be transferred as objects through messages, and inflated by a certain processes for it to increase resource share.
To improve control within and across groups of processes trusting each other, the notion of currency is introduced to represent share of tickets within each trust boundary. Each trust group may get certain ticket share from kernel in terms of base currency, and processes within each group may be allowed to inflate, deflate and transfer currency locally.
To guarantee resource share of a process not utilizing all of its quota, it will be compensated with more tickets in the current quantum to probabilistically increase it would run until the next quantum.
4. Evaluation
The authors implemented a prototype lottery scheduler for the Mach 3.0 microkernel on a 25MHz MIPS-based DECStation 5000/125. The scheduler is tested under relatively simple benchmarks as well as more real-world workloads. Fairness is tested by measuring the allocation ratio multiple running processes, which seems steady and fair in the long-run. The flexibility of control is shown where they use specific ticket sharing policy adapting to a Monte-Carlo Experiment scenario. The two real-world simulation on Client-Server model and multimedia applications show a good processing throughput of the scheduled processes. The load insulation is shown when five processes are scheduled within two trust groups. Finally they estimate the overhead of the scheduler and conclude that as comparable to the original scheduler in Mach kernel.
From the charts shown in this paper, the performance is mostly presented in terms of throughput over a period time. In some real-time application scenarios, however, latency also seems to be a very important factor. It might be good to show the average and worst case latency on those applications.
5. Confusion
Maybe in class we can talk about how the notion of priority is not possible to implement such flexible controls as presented in Lottery Scheduling?

Summary
The paper presents lottery scheduling, a novel randomized proportional share resource allocation algorithm that provides responsive control over the relative execution rates of computation. Resource rights are represented by lottery tickets and allocation decisions are made via lotteries. Resource allocation is proportional to the number of tickets held by a process.
The problem
Systems that service request of varying importance like the database, multimedia applications etc desire flexible control of computing resources. Problem with priority based scheduling is that assigned priorities are ad hoc and absolute resulting in very crude control over scheduling. Fair share based schemes adjust priorities by using feedback loops but only achieve long term fairness. Schemes using decay usage scheduling which is a type of priority-aging time sharing scheduling are poorly understand. Conventional schedulers also suffer from the problem of priority inversion. Hence in a nutshell , traditional schedulers are complex and difficult to control with hard to understand behavior .This motivated the authors to come up with the conceptually simple and easily implementable lottery scheduling .
Contributions
1.The lottery tickets are
abstract-operate independently of machine level details
relative-chance of winning the lottery depends on contention level
uniform-can homogenously represent heterogeneous resources
2.Lottery scheduling is probabilistically fair. The number of lotteries won by a client has a binomial distribution while the number of tries required for the first win has a geometric distribution. It solves the problem of starvation as every client with tickets have a non zero probability of being scheduled.
3. To deal with dependencies , tickets can be transferred from a blocked client to a server. This eliminates priority inversion. The paper also talks about ticket inflation which is an alternative way of ticket transfer. Mutually trusting clients can dynamically adjust their priorities without explicit communication by creating or destroying tickets. I/O bound processes are likely to get less than their fair share of CPU time as they often block before the expiry of their quantum. Compensation tickets address this imbalance by suitably inflating the value of the process’ tickets.
4. Lottery scheduling provides excellent support for modular resource management. Load insulation is provided via currencies where in a user manages multiple threads without impacting others. The idea is that inflation can be locally contained by expressing the tickets in a new currency which has a variable exchange rate with the base currency. Currency relationships can form any arbitrary acyclic graph.

5.Lottery scheduling can be generalized to manage many diverse resources like I/O bandwidth, space sharing memory, access to locks etc.
6. One of the most remarkable features of lottery scheduling is its use of randomness which is not only lightweight and fast but also avoids several corner case behaviors that a more traditional approach might have trouble handling.
Evaluation
The paper provides a series of comprehensive experiments to quantify the flexibility and responsiveness to control the relative execution rates of computation. The first experiment demonstrates fairness by running two tasks of Dhrystone benchmark thrice with varying relative ticket ratio. We observe that the observed iteration ratios are close to their allocated ratios . Dynamic control of ticket inflation is shown by running three staggered Monte –Carlo numerical integration program with ticket values assigned as function of the current relative error. This type of flexible control would be impossible for a conventional scheduler. A multithreaded client server application for searching text demonstrates the effectiveness of ticket transfers. Lottery scheduling enables control of quality of service for multimedia applications. The paper also demonstrate load insulation by running two tasks, and launching extra threads in one of them mid-way, to show that the other remains unaffected. The overhead imposed by the prototype lottery scheduler is comparable to standard Mach timesharing policy.An unanswered question requiring evaluation is that can we force the lottery scheduler to be unfair? Is there a way to use compensation tickets to get more time, e.g., quit early to get compensation tickets and then run for the full time next time? Also an analysis whether the differences in the actual execution rati and allocated ratios are statistically significant-is the lottery biased or there is a secondary force affecting the relative priorities (eg-X server for multimedia applications) would have been helpful.
Confusion
How can the tree-based lottery scheduler be extended to a distributed model?
Who assigns the tickets? The paper talks of an user level interface for creating and destroying tickets, does this mean it is done by the user? If so then is it not unsafe, eg an user can greedily assign itself arbitrarily large number of tickets. If the assignment is done by the OS, then on what basis? Also what is the purpose of user level ticket management in this scenario?
How to merge preemption and lottery scheduling?

1. Summary
This paper presents lottery based scheduling mechanism, which is a randomized resource allocation algorithm and allocates resources proportional to the number of tickets held by a process. The authors show that it provides an effective responsive control over relative execution rates of computation and also could be used to manage many diverse resources.

2. Problem
The authors mention about the need to rapidly focus the available resources on processes that are of immediate importance. Priority based scheduling offer this but lack fine control as resource rights do not vary effectively with priorities. They also do not provide encapsulation and modularity.
Fair share schedulers are complex and microeconomic schedulers have overhead of bidding , so there is a need to have a better scheduling algorithm.

3. Contributions
The authors in this paper discuss Lottery scheduling which presents a notion of efficient implementation of scheduler such that resource consumption rates of active computations are proportional to the relative shares that they are allocated. The resources are granted by holding a lottery to the winning client in proportion to the number of tickets held. Lottery tickets are abstract and provide quantification of resource rights independent of machine details. To provide isolation to trust boundaries concept of Ticket currencies is introduced where each group can maintain a unique currency to denominate tickets within the boundary. The tickets can be inflated/deflated dynamically reassigned and the internal policy of the trust boundary doesn't affect the overall scheduling policy of the system. Compensation tickets are granted for achieving true fairness to processor allocation. Ticket transfers allow quick scheduling of blocking threads and offers an easy solution to priority inversion. The lottery idea can be generalized to resource constraints mutexes, I/O, memory space etc.

Evaluation:
The authors have evaluated the prototype by conducting experiments on compute-bound Dhrystone benchmark, Monte-Carlo numerical integration program, multithreaded client-server applications and MPEG video viewers. Executing tasks on Dhrystone benchmark they have shown that scheduler achives resource allocation relative to ticket allocation. Dynamically controlled ticket inflation is evaluated using Monte-Carlo algorithm. Using custom client-server model, they have shown that ticket allocation affects both response time and throughput. The authors also showed that media based applications also benifit from the schdeuler by comparing the display rates when two viewers are displayed. The overhead of the implementation is comparable to the unmodifed Mach kernel. The reason for choosing randomized algorithm over traditional scheduling algorithms I think needs a better explanation from authors. It would be more insightful to see more benchmark experiments of total execution time with the prevalent scheduling algorithms.

5. Confusion
The topic of funding policies in this scheduler needs more discussion.

summary~
In this paper, the authors present the lottery scheduling mechanism for resource allocation. It utilize randomization to achieve responsiveness and fairness.

problem~
Traditional scheduling mechanism that relies on the notion of priority come close to flexibility and responsiveness control, but poorly support modular resource management. Other approaches like fair share schedulers and microeconomic schedulers address some of the issues, but they are not flexible due to their assumptions and overhead. Scheduling mechanisms that provides responsive control, flexibility and support for modular resources management are needed.

contributions~
The introduction of randomization here helps to address the issue of fairness. Fast responsiveness is easily provided by ticket allocation. They also introduce the idea of currency which can be created on demand, this helps to provide isolation so that the the condition of inflation can be contained. The idea of ticket transfers among trusting process helps to solve the priority inversion issue. Finally, they made very little assumptions in designing the lottery schedule mechanism, so it can be generalized into other places. So that it can be applied on managing I/O bandwidth, memory and even access to lock.

evaluation~
They implement the prototype by modifying Mach 3.0 Microkernel. In the evaluation, the authors justify the fairness, responsiveness, isolation of the lottery scheduling. The observed ratio is close to the ratio of tickets allocated. The client-server model are used to demonstrate the responsiveness. They also calculate the overheads of their implementation and compare to the standard Mach implementation to demonstrate the small overhead of their implementation. All these together sufficiently justify their hypothesis.

confusion~
Not every architecture will provide efficient hardware instructions for generating random number, if the hardware cannot generating random number efficiency, how are they going to solve the issue of overhead~?

Summary
The paper presents a probabillistically fair scheduling scheme for resource management called lottery scheduling. This new technique was introduced to provide efficient, responsive and protective control over the relative usages of resources.

Problem
Traditional scheduling techniques did not provide good flexibility and a reliable control over resources over a varied tasks such as databases, media based applications and networks. The ones that provided were priority based and did not provide protection required for large software systems. Even with some fair-share and microeconomic schedulers, there existed assumptions leading to overheads in using those. The authors aim to resolve these issues with lottery based scheduling.

Contributions
The paper presents the design and an implementation of lottery based scheduler on a Mach 3.0 microkernel.
a. The authors use an approach fairly easy to understand than that of traditional schedulers while solving the scheduling problems. It uses an economic model of allocating shares of a currency in the form of tickets and then running lotteries to determine the scheduling order.
b. It ensured probabilistic fairness by providing resource allocation proportional to the number of tickets each process had.
c. Such use of tickets introduced modularity and hence gave a protection control.
d. The tickets could be transferred from one client to another and also could be inflated among mutually trusting clients to escalate a process's resource rights.
e. A currency relationship was maintained among different local currencies. Such local currencies confined the inflation to local clients and base currency was conserved with a (dynamically) defined exchange rate.
f. Also, a client is awarded with compensation tickets in case of fractional usage of resources. Such adjustment helped in retaining the probability of winning a lottery.

Evaluation
The overall evaluation seemed good enough with benchmarks tested over the various additions in the scheduling system. To test fairness, two tasks were run with different ticket allocation ratios for 3 times and the results show a proportional iteration ratio. The flexibility of dynamic control of tickets was tested with 3 tasks running Monte-Carlo algorithm at different times and the results prove on it's efficient response time for the new incoming tasks. The transfer of tickets was effectively shown with a server-client architecture where the server had no tickets and only relied on clients for tickets to service queries. Even with such environment, the query processing rates were proportional to the ticket allocation for clients. They also demonstrated the kind of application control that one can achieve with lottery based scheduling with multimedia applications. Ultimately, they just describe the system overhead briefly over an unmodified Mach microkernel. Though, this would have been much better with an evaluation of memory overheads for their system. A classic comparison with the traditional ones would have made it more clear and support their accusition of traditional fair-share schedulers creating overheads.

Confusion
How are the tickets intially allocated to a process ?

1. Summary
This paper presents Lottery Scheduling, a new resource allocation mechanism that provides flexible control over the relative allocation rates of various contenders. It provides modular, randomized, dynamically changeable and flexible proportional-share resource management. Rights to resources are abstracted in terms of lottery tickets, and each contender has a number of tickets. Each time the resource is allocated, a ticket number is randomly selected, and hence each contender has a chance proportional to the number of tickets it holds. Lottery Scheduling can be generalized to any resource sharing scenario, but is discussed and implemented primarily in the context of CPU scheduling here.

2. Problem
Scheduling in multi-threaded systems is a complex problem. For computation intensive CPU bound processes, allocation of the CPU to various tasks should be regulated. For interactive tasks, users need the ability to rapidly focus resources on tasks that are currently important.
Priority based - lack modularity and encapsulation. Assignment - challenge.
Decay usage - complex algorithms. Fixed, compute-bound workloads.
Fair share - book-keeping, overheads. Not suitable for interactive.
Micro-economic - auction systems. Bidding overheads. Not suitable for interactive.

3. Contributions
Tickets - abstraction of resource rights. Multiple tickets are assigned to each contender (such as a process).
Lottery - random ticket number [0, numTotalTickets] is generated, process to which it belongs is scheduled.
Probabilistic - By assigning tickets to processes, probability of being scheduled, and hence relative importance, can be controlled.
Modularity - A unique currency is used to denominate tickets within each trust boundary. Currency relationships can form a directed acyclic graph. Exchange rates are maintained between the base currency and the derived currency.
Ticket transfers - solves the priority inversion problem in an efficient, modular manner. Tickets can be transferred whenever one task is blocked due to a dependency on another task. Compensation tickets are used when a client uses only a fraction of its allocated time. Ticket Inflation by a client, which is increasing the number of tickets assigned to itself, can be done between mutually trusting clients.
Diverse Resources - can be used to control relative waiting times of threads competing for locks, or for I/O bandwidth sharing, etc.
Space shared resources - inverse lottery - loser is picked, probability inversely proportional to number of tickets possessed.
Multiple resources - can use a single currency to manage multiple resources, though orthogonal currencies might be more appropriate.

4. Evaluation
Implemented on a Mach 30 microkernel, with a timeslice of 100 ms. Comparisons are made with the default timeslicing scheduler.
Compute-bound Dhrystone benchmarks were used to test fairness.
Monte-Carlo experiments were used to test dynamic adaptation and flexibility.
Client server applications were used to observe response time and throughput to check if relative importance was maintained.
Multimedia applications - Video display frame rates - 3 competing applications.
In all the above cases, observations were in-line or very lose to expectations.
Overhead - marginally fewer iterations of scheduler were run, (2.7%) but within std deviation of mean of the base Mach OS scheduler.

My Opinion
Some high-priority threads, such as the Ethernet driver, remain under original fixed priorities, which hints at distrust of the non-determinism in lottery scheduling,
The challenge of ticket allocation policies has been left open.
While lottery scheduling gives finer grained control than priorities, the same weakness, of arbitrary ticket numbers / priorities, applies.

5. Confusion
Why eviction instead of allocation in space-shared resources?
Why used fixed priority for important tasks?
Explanations on decay-usage, market based, micro-economic approaches.

1. Summary

This paper presents a randomised resource allocation mechanism called lottery scheduling.

2. Problem

The existing scheduling schemes do not provide an excellent flexible, responsive control as they rely upon priorities. The fair share schedulers and the microeconomic schedulers that address problems with absolute priority schemes have assumptions and overheads associated with them. Thus, a randomised scheduling approach was developed. Random approach avoid corner-case behaviours, are lightweight and fast.

3. Contribution

The main contribution of this paper is description and implementation of the lottery scheduling that implements a proportional share resource management system. Lottery tickets provide encapsulation of the resource rights that are abstract, relative and uniform. Scheduling of lottery is probabilistically fair as the expected allocation of resources to clients is proportional to the number roof tickets that they hold. The starvation problem is eliminated as every client holding a ticket will eventually win a lottery. The tickets provide a modular resource management as they can be treated as first-class objects that may be transferred in messages. It explains the concept of ticket transfers, ticket inflation, ticket currencies and compensation tickets for implementing resource management policies with lottery tickets. The paper also provides various implementation and optimisation details of the scheduling system. The system is implemented by modifying the Mach 3.0 microkernel. The pseudo-random number generator implemented was based on the Park-Miller algorithm. A centralised list or tree can be used for ticket implementation. The scheduling interface is exported by the microkernel interface. The modified mach_msg system call transfers tickets from client to server for synchronous RPCs. User Interface for manipulating command-line interface was also available. The prototype for ticket currencies and compensation tickets is also described.

4. Evaluation

I really enjoyed reading about the various experiments carried to evaluate the performance of the system in achieving its flexibility and goals. The scheduler demonstrates fairness over the relative execution rates of computations. The impact of the dynamically controlled ticket inflation on Monte-Carlo algorithm was studied. A multithreaded client-server application that shares properties with real databases and information retrieval systems was developed and effect on the client-server computation through ticket allocation was studied. The control at the operating system level through ticket allocation was demonstrated in a multimedia applications. The currency attraction was used to flexibly isolate users, tasks and threads. The system overhead was comparable to that of the standard Mach timesharing system. Management of diverse resources such as processor time, I/O bandwidth and lock access using lottery scheduling was demonstrated and evaluated, proving it to be comparable to the existing systems. Overall, experiments carried out were relevant to the purpose of the system and their performance measures were accurately analysed.

5. Confusion

1) How are the total number of tickets to be allocated in a system decided?

1. Summary: This paper is about lottery scheduling, which is a probabilistically fair scheduling algorithm, that provides flexibility and isolation over resource control, in addition to being fair. Lottery scheduling operates by assigning appropriate tickets to tasks and drawing a lottery each time a scheduling decision is to be made. In addition, the authors show that lottery scheduling can be used to control access to a lot of shared system resources.
2. Problem: Tasks can be of diverse nature: compute-bound, IO-bound, highly responsive, real-time etc. Not a lot of contemporary general-purpose scheduling algorithms existed that responded well to all types of tasks. The ones that existed, used priority-based approaches, but they did not provide encapsulation and modularity. The control offered over the resource was also not flexible enough. Then there was this problem of coarse-grained control. Policies like fair-share scheduling, although being proportionally fair, operated at the granularity of users. The scheduling algorithms used in the OSs that time were not properly understood. In order to provide optimizations, or handle some cases, they ended up making some machine-specific changes, and were not abstract as well. The authors aim to solve all this with a single algorithm!
3. Contributions: The authors solved all the problems mentioned above with a single algorithm. They also borrow from well-understood economics abstractions to make their case easily understandable! The key highlights of their algorithm are:
a. It is probabilistically fair. The more tickets a process has, the more is its chance to be selected.
b. The probabilities and expectation values follow simple distributions such as binomial and geometric. These are widely understood, and well-researched, thus removing the element of ‘black art’ associated with previous approaches, since they were not understood.
c. The algorithm introduced the abstraction of tickets, making it machine independent.
d. Every process has at least one ticket, and so its probability of selection is non-zero, thus avoiding starvation.
e. Each task can spawn multiple threads and assign them a currency of its own. Thus, the overall share of the task doesn’t increase. Rather, all other threads of this task give up some of their share. Thus, the granularity of control is at task-level!
f. The implementation allowed tickets to be transferred from one process to another, aiding in a modular resource management. This would help in policies like providing more CPU time to servers, in case clients are waiting, or in faster release of a lock, when multiple threads are blocked on it. This also meant that problems like priority inversion are solved by default, and no special mechanisms are needed.
g. The concept of ticket inflation allowed tasks to dynamically change their shares, and CPU time. This also provided an extra flexibility.
Thus, all the problems were solved in a single shot. Moreover, it is remarkable that they do this extremely simply, using a pseudo-random number generator, thus preventing extra overheads too! They also successfully demonstrate their algorithm for scheduling locks, and even memory.
4. Evaluation: The authors provide a comprehensive performance evaluation of their implementation with proper reasoning at all places. To measure fairness, they launch three runs of a process, and assign it tickets in different ratios, and measure the actual number of iterations. They run Monte-carlo algorithm and demonstrate extreme flexibility, and dynamic control. This would be impossible in conventional schedulers. They also demonstrate successful use of their ticket transfer policy by running client-server loads. They also demonstrate a task-level control and insulation by running 2 tasks, and launching extra threads in one of them mid-way, and showing that the other remains unaffected. In most of the cases, they show that over sufficient time, the observed ratio equals the estimated probability of selection. In addition, I would like to see a memory footprint of their implementation, and how does it vary with the implementation. Ex: It may be interesting to know how much memory is used up by a tree structure holding the tasks, and how it compares with queues in conventional schedulers. In addition, they don’t provide an explanation of how their algorithm scales with the number of tickets? For ex. a billion tickets?
5. Confusion: How are ticket numbers assigned? If ticket numbers are assigned consecutively, what would happen when a process exits? This would create gaps, and tickets may have to be re-numbered. With the idea of compensation tickets, it seems that this policy will be good for processes that are ready to take the CPU again quickly. Is this correct? Why is this approach not used in Linux kernels?

1. Summary
The paper introduces lottery scheduling, a randomized scheduling algorithm. This systems responds very fast to changing resource requirements and task priorities. It also allows for modular resource management by encapsulating priority as currencies. This scheduling policy was prototyped on the Mach microkernel to manage the CPU but it can be generalized to other resources with different sharing needs.
2. Problem
Scheduling a CPU or any other shared resource is a complicated problem. In order to save overheads most algorithms rely on global priorities which allow coarse grained scheduling. These algorithms did not allow modular resource control (encapsulation) or control over relative execution rate. Hence setting up the correct global priorities requires a lot of tuning. Moreover, these systems do not react quickly to changes in priority which is critical for various user facing/ graphics rich applications.
3. Contribution
The paper introduces lottery scheduling with priority being proportional to the number of lottery tickets held by a user/task/thread. The unique contribution here were currencies. Each currency allowed a user/module to dictate the relative priorities of its subtasks (adding/deleting tasks) independently of the rest of the system. Various currency could also be traded as they could all be converted to the base tickets based on the funding of the module distributing the currency. This exchange allowed tasks to dynamically change priorities based on contention for locks/blocking on a lower priority task far quicker than priority inversion would achieve the same in a traditional scheduling algorithm.
4. Evaluation
The authors evaluate this solution based on its ability to respond to changes in relative priorities and its adherence to those priorities. They test to see whether several tasks are assigned CPU times proportional to their priority. Even though there is variation, the system tends to converge to the priority ratio. They also test responsiveness by introducing new tasks or changing priorities and seeing whether this impacts different tasks using the same currency without impacting other system tasks. The system also measures the overhead of the lottery implementation over the default Mach scheduler and find that the lottery scheduler adds some overhead due its POC nature but outperforms Mach in workloads where ticket transfers were needed. Overall the solution is well evaluated to show its various use cases. However I am left with a few questions. The authors did not break down the overhead introduced by lottery scheduling especially the overhead of conducting a lottery at each context switch vs picking the next element from a priority queue. The authors do mention various mechanisms to reduce this workloads such as using tree data structures, but a time comparison of one context switch in both cases would help me understand the cost of things like random number generation when performed in the performance critical path. Another issue not discussed is how to handle deviation from relative priorities when time (n) is not sufficiently large. I see this being a problem for various short lived high priority jobs which may not stick around long enough to converge to the correct relative priority,
5. Confusion
Why are tickets destroyed in the transfer case, why are they not passed back to the client?
How does the mutex currency relate to the base currency?

1.Summary:
This paper introduces the lottery scheduling which is a randomized resource allocation mechanism. Lottery scheduling also provides responsive control over relative execution rates of the application processes. The authors have implemented this on Mach 3.0 microkernel and evaluated its features.

2.Problem:
The existing schedulers were difficult to comprehend, did not provide fine-grained, modular resource management techniques and responsive control over the execution rates. Priority based schedulers had the issues of dynamic priority adjustments which was ad-hoc. Schedulers such as fair share schedulers due to their overhead, provide only coarse grained control over resource consumption rates and this affected interactive applications. Lottery based scheduling address all the above mentioned issues.

3.Contributions:
1) Resource allocation is proportional to the share of the lottery tickets the clients hold in the system. It is shown to be fair probabilistically and avoids starvation since every client holding tickets win the lottery at some point.
2) Lottery based mutex implementation is done by the concept of ticket transfers. Here, all the threads waiting on a lock transfer their tickets to the one holding it, allowing it access to more resource shares.
3) Currency based tickets, where each currency is local to a group of mutually trusting clients. This abstraction allows protection, sharing of resources within it, ticket inflation to obtain larger share, thus providing modular resource management.
4) Compensation tickets are provided to clients which execute only fraction of their allocated resource quantum. This ensures fair share of the resources.
5) The authors also show how their lottery based mechanism can be used for managing diverse range of resources, resource revocation by inverse lottery scheduling etc.

4.Evaluations:
The authors evaluate lottery scheduler by implementing its prototype on the Mach 3.0 microkernel on a 25MHz MIPS based DECStation. Their evaluation measures fairness where they show that the execution rates are proportional to the ticket allocation ratios by running two tasks of the Dhrystone benchmark. Monte Carlo algorithm is run to measure effectiveness of ticket inflation where the error rates determine the resource shares. Ticket transfers are evaluated in a client-server setup where the clients transfer their tickets to server for running queries on it. In all these experiments, the graphs show that the execution rates ratios are similar to the resource allocation ratios of the clients.
Some missing evaluations would be for variable scheduling quanta(unlike fixed one here-100 ms), what happens when scheduling quantum decreases, does this increase the overhead of conducting lotteries?. The cost of ticket transfers through message passing is unknown from the evaluations. Finally, they compare lottery scheduling with unmodified Mach where 2.7% fewer iterations were executed in the former. Further optimizations would reveal if this mechanism is effective than existing schedulers.

5.Confusion:
How are the initial ticket allocation rates for the processes decided?
How do co-existing multiple schedulers work?

Summary:
The paper proposes a novel, randomized scheduler that aims to be responsive to changing application needs, be fair in allocating resources proportionally and support modular resource management.

Problem:
Most general purpose schedulers at the time relied heavily on absolute, static or slow and dynamically changing priorities for resource allocation. Hence these are not responsive to fast changing application needs. These do not support borrowing and lending resources from/to trusted clients, such as threads of a task. There was a need for responsive, efficient and flexible scheduler.

Contributions:
1) The paper borrows the main idea from the working of a lottery. Tickets are allocated to tasks based on their desired execution rates. The more the value of the tickets, the better chance of getting CPU time at any particular scheduling quantum. The standard deviation between the expected relative execution rates and the share of tickets allocated is reduced either with long running tasks or with a smaller scheduling quanta.
2) The paper aims to support modular resource management in the scheduler by a number of methods. Ticket transfers are done by idle waiting threads to other threads in the task that may require immediate execution. Ticket inflation could happen within a task when a thread in the task needs immediate resource allocation. This effect is isolated from other tasks in the system through the concept of Ticket currencies where each task may contain a number of tickets that are backed by some currency. The currency has a conversion rate with the base currency which is always used while calculating the global share of resources amongst tasks.
3) The scheduler compensates tasks that take up time lesser than their scheduled time slice before yielding. I/O bound applications are an example. In such cases the ticket allocation is inflated proportional to the fraction of time the task left unused in the previous scheduling quanta. This maintains proportional CPU time between tasks that are heterogeneous (I/O bound or compute bound)
4) This lottery scheduling is implemented for threads waiting to acquire a mutex. Threads waiting on a mutex lend their tickets to the thread that is currently holding the task. The thread once released is more likely to be acquired by the thread that initially had tickets with the highest value.

Evaluation:
The authors have evaluated the scheduler running compute-intensive monte carlo workloads, database workloads that have idle waiting threads and video-applications. Fairness is demonstrated by running tasks with different ticket allocation ratios and comparing the relative execution rates. Monte-carlo tasks are run with resource requirements that decrease with time. A number of such tasks are run starting at different times to demonstrate the flexibility in control that the scheduler exports to the user.Client-server workloads are run to demonstrate the effectiveness of the ticket transfer feature. The servers do not have any tickets assigned directly to them. Although the scheduler works as expected, difference in query processing times when servers have their own allocated tickets could have been shown to point out the advantage of ticket-transfers. The paper also evaluates the overheads of the lottery scheduler and the native mach scheduler. The lottery scheduling is slow even with a tree based winner identification. However, the paper has not clearly stated the reasons. Profiling of time spent inside the scheduler could give a better idea. The paper has also evaluated the lottery scheduling of threads waiting to acquire a mutex and the results conform to the expected behaviour.

Confusion:
The paper talks about lottery scheduler coexisting with the native priority based tasks such as system services. How exactly is that achieved?

1. Summary
The authors came up with an efficient modular resource management technique which could provide fine grained control on the underlying resources. So, they proposed Lottery scheduler which used ticket based mechanism to allocate ownership on a particular resource and then randomly select a candidate.

2. Problem
Existing solution had complex algorithms and did resource management at a coarse grain as described for the fair share scheduler. Other related works such as microeconomic scheduler had bidding system which could get too volatile otherwise. So, there was a need to come up with a solution which could manage resources efficiently.

3. Contribution
The authors came up with Lottery based scheduler which randomly allocated resource to a process based on the number of tickets it had. Explicit representation of resource rights as tickets used to insulate resource management policies of independent modules solved modular resource management problem. They also talk about transfer of tickets based on a particular currency in which a ticket was defined. By allowing cooperating processes to inflate the number of tickets they owned, it could increase the probability of owning a resource. To ensure fairness to the process which used only a fraction of its run time, they proposed compensation tickets which will will escalate its tickets equal to the inverse of the fraction of the tickets.
Their implementation also talked about optimization in random number generator by enumerating the underlying assembly instructions and then quickly finding the winner of the ticket by reverse sorting the tasks based on the number of tickets. Further optimization in form of tree based lookup can reduce the runtime to O(logn).
The authors also talk about the ticket currency which was a representation of base tickets and was used to assign to tickets to subtasks within a group. The ticket currency was also used to transfer between users or tasks. This ensured that if there was a process which was blocked waiting to acquire a mutex, it could transfer its tickets to the the process holding the lock but having less number of tickets, essentially addressing the inverse priority problem. However, it was not exactly clear how will the process identify which process was holding the mutex.
Also, the authors used probabilistic models which proved that their scheduling policy was fair - associating binomial distributions to show the number of lotteries won by a client and geometric distribution to explain client’s first win for a resource. Overall, this approach seems to be a powerful technique which can be used for resource management and not just limited to scheduling. Memory management could be done by inverting the probability, thus a candidate with highest tickets has the least chance of its resources being revoked.

4. Evaluation
Although the authors did a comprehensive test such as fairness, flexibility for the techniques introduced by them, they could have also provided profiling details of the individual components such as the overhead of ticket transfer, ticket inflation. This profiling could have helped in identifying the exact overhead introduced for the Dhrystone benchmarking process which showed that their implementation does 2.7% fewer queries.

5. Confusion
I did not understand why such a promising technique was eventually not used in current systems and specifically what is the improvement done in fair share scheduler (completely fair scheduler which is used in linux kernel today).

1. Summary
This paper describes lottery scheduling that is nothing but a randomized resource allocation mechanism. The main aim of the proposed solution is provide efficient and responsive control over the relative execution rates of computation. The authors achieve the goal by introducing an abstraction known as currency. The aforementioned abstraction also enables support for modular resource management that is an added advantage. The authors implement the proposed solution for Mach 3.0 microkernel and the initial results seem promising.
2. Problem
Traditional schedulers have a number of shortcomings. They are unable to provide the fine-grained control that is required for efficient sharing of resources. Another disadvantage of existing schedulers is that they are complex, non-modular and lack the required flexibility. There is a need for fine-grained control over the relative computation rates to allow for efficiently scheduling the shared-resources in multithreaded systems. Also, the current schedulers do not have dynamic control over scheduling. This is a major requirement for interactive systems. The authors try to propose a solution that is free of all the above-mentioned shortcomings.
3. Contribution
The main contribution of the proposed solution is the use of tickets to guarantee probabilistically fairness. According to me the simplicity of the design is one of the key takeaways from the paper. Though the abstraction of tickets seems to be a simple one, yet it is powerful. The proposed solution achieves modularity by the use of tickets. The tickets can be transferred from one client to another and can be inflated among trusting clients. Another useful contribution of the authors is the introduction of the currency abstraction that enables flexible naming, sharing and protecting resource rights. Through currencies, maintaining an exchange rate between each local currency and the base currency can locally contain the effects of inflation. In other words, currencies ensure that the proposed solution is modular. Lastly, the authors also introduce the concept of compensation tickets which rewards a client that consumes only a fraction of it’s allocated quantum so that it continues to receive what it’s entitled for.
4. Evaluation
The authors implement the proposed solution by modifying the Mach 3.0 microkernel on a MIPS-based DEC Station. This implementation is used to evaluate the various dimensions of the scheduler such as flexibility, responsiveness and control over the computation rates. The prototype is evaluated using compute-bound Dhrystone benchmark, Monte-Carlo programs, multithreaded client-server applications and competing MPEG video viewers. Across the various experiments that are carried out, the results bring out the fact that proposed solution is fair. Through the use of the Monte-Carlo program the authors show effectiveness of the inflation/deflation of the tickets (proves that the scheduler supports dynamic changes). Through the use of client-server application the authors demonstrate the mechanism of ticket-transfer. Though the authors have done an extensive evaluation, there are a number of shortcomings regarding the same. Firstly, the distortions in the results of the Multimedia case needs to be investigated more deeply. Secondly, the authors haven’t carried out an analysis of the proposed mechanism of compensation tickets. Thirdly, the authors do speak about a number of optimizations that could be used to implement the lottery scheduler more effectively but fall short of identifying the bottlenecks in the current version of the scheduler. Lastly, the authors do not compare the performance (apart from overhead) of the proposed solution with other existing traditional schedulers. A comparison would help us appreciate the enhancement offered by the proposed solution.
5. Confusion
I do not clearly understand how this mechanism would be extended across multiple resources. A discussion regarding the same would be ideal.

1. Summary
This paper introduces the lottery scheduler, a highly responsive and flexible fair share scheduling scheme. It also introduces the abstractions of tickets and that of currencies which provide resource control and load isolation among users/processes/groups.
2. Problem
The key problem in multi-user scheduling is to handle proportional share for different levels of allocation such as groups/users in a modular fashion and respond quickly to changes in allocation. Past priority based schedulers tend to be ad-hoc and difficult to work with in terms of load isolation. Though Fair share schedulers [Kay 84] give most of the insulation properties among resource groups, they require book-keeping and complex algorithms to adjust the priority of processes. Also such methods have slower response time and only provide steady state fairness.
3. Contributions
Lottery scheduling uses a randomized resource allocation algorithm using tickets to represent shares. This provides a probabilistic fair share guarantee.
1- The paper introduces the abstraction of a ticket as a unit/share of resource allocation. Since ticket are objects in themselves they can be freely transferred among threads, which is unlike a priority number.
2 - The lottery only considers threads that are actually contending on a resource (CPU) which is why the value of a ticket is relative to the active tickets The probabilistic guarantees ensures no thread is starved, and the algorithm reacts quickly to changes in allocation/tickets.
3- Thirdly, the paper introduces the idea of currencies which abstract fair share among resource groups at different levels. Thus, the base value of a thread’s tickets is calculated by appropriately weighing the value of the shares at different levels. This gives effective load isolation in a simple manner.
4- Tickets can be transferred to a thread in a different domain, this could be used to implement RPCs where the server thread gets the same tickets as the requesting client (funding).
5- Lastly, special compensation tickets are allotted when a thread uses only a fraction (f) of its time quantum due to reason such as I/O. This ensures the threads chances of being scheduled are inflated by a factor 1/f as the scheduler does not store use usage information.
4. Evaluation
The authors show that the random lottery does converge to the fair share value over a reasonable time interval. They also prove load isolation is achieved using currencies, by comparing the cumulative resource usage of two currencies when a new thread is spun in one of them. Experiments also show that fair share is retained by ticket transfers in RPCs. In these results one can see how the scheduler responds quickly to a change in allocation, but the authors do not provide a metric measure of response time. Also the scheduler should have been compared to prior art methods for response time. Lastly the authors do not evaluate the effectiveness of compensation tickets, or how the scheduler performs with a mix of interactive and batch jobs.
5. Confusion
Could you explain more on the problems with fair-share schedulers [Kay 84] , as to why they were more complex.

1. Summary
This paper introduces randomized resource allocation mechanism with proved modularity, flexibility and responsiveness depending on lottery ticket distribution desirable in databases, media-based applications and networks. It utilizes random “ticket” generator and partial ticket sum tree to schedule client, ticket and currency objects for modularity, compensation ticket for fairness and ticket transfers for throughput.
2. Problem
Scheduling in multithreaded systems require relative computation support for accuracy, regulation of shared resources and responsiveness for interactive computations. Present priority based schemes do not provide encapsulation and modularity and priority assignment are often ad-hoc. Fair share schemes have coarse control over computations not suitable for dynamic interactive systems.
3. Contributions
Lottery tickets encapsulate resource rights which are: abstraction independent of machine, relativeness for resource alternatives and uniformness between heterogeneous resources. It is starvation-free since each process is guaranteed non-zero probability of being selected. It is also probabilistically fair with throughput and accuracy proportional to ticket allocation and fast-adaptive to allocation changes. Priority inversion is eliminated with ticket transfers between blocked client and server. Ticket currency ensure flexibility by letting user favor its child threads without impacting threads of other user. Compensation tickets address the imbalance between IO-bound and compute-bound by ensuring fair share of CPU. It is also used in controlling relative waiting time of threads competing for lock access. Inverse lottery can efficiently provide similar gains for space-shared resources. Lottery scheduling being simplistic due to randomness has applicability in GUI elements, virtual circuit bandwidth and multiple resources. This also proved to be more lightweight with only tree-structure for managing lotteries and random number generator.
4. Evaluation
Authors implemented prototype for Mach3.0 microkernel with workload consisting of compute bound and multithreaded client-server application. Scheduler controlled computation rates fairly and accurately even with shorter time intervals. It manifests flexible control by dynamically adjusting ticket value as a function. Introduction of extra client do not make difference in ticket-allocation based computation of queries. Though there is a scope for further optimizations to list-based lottery and simple currency conversion scheme, overhead imposed by current implementation is same as time-sharing policy. In its applicability in synchronizing resources, throughput and response time of contending threads closely matched its ticket allocation. Gain here is the increased amount of information the scheduler has in order to make informed decisions about what to do next. On the other hand, it fails to provide responsiveness for mixed interactive and CPU-bound workload offered by decay-usage priority scheduler and also ignores kernel priorities used in BSD scheduler to reduce kernel lock contention.
5. Confusion
How does lottery scheduling react to nice utility present in UNIX? And how does ticket transfer add benefit relative to kernel priorities which encourage processes to release kernel resources quickly?

1. Summary
This paper talks about a new idea of scheduling called "lottery scheduling" which is responsive, efficient and uses randomization to achieve its goals. The paper explains the concepts of tickets & lotteries and also how they can be used to provide modular resource management. Finally it discusses its implementation and evaluation details

2. Problem
Scheduling is a challenging concept especially when you need to deal with varying relative computation rates for different applications, multi-resource, multi-threaded environment. Most of the techniques have only coarse-grained control and some of them which can provide proportional share for each applications have high overhead and need to keep track of lots of state information

3. Contributions
The paper proposes the idea of lottery scheduling which uses tickets to represent the share of each application and also uses the properties of probability (binomial and geometric distribution) to provide fairness. This is an interesting idea and one of the main novelties of the paper. The paper then talks about the tickets & currency concepts related to lottery scheduling. They have provisions to both transfer tickets and inflate tickets(only in trusted environment). They also propose the idea of compensation ticket to ensure fairness. Another thing which I found interesting was the idea of using currency as an abstraction to provide sharing and load isolation.
This idea of local currency can provide modularity and It would be interesting to find out how they came up with this idea instead of just using a global currency system?

4. Evaluation
I liked the evaluation part of this paper as they were able to justify all their major decisions ( achieving their goals of dynamic, flexible control, fairness etc). But the one thing which I found missing was the overhead evaluation.
They showed that the fairness achieved using their method was close to ideal (large ratio's eventually converge to their fair share). They also showed that it was able to provide dynamic control using compensation tickets (using staggered monte-carlo tasks workload), change in ratio is reflected quickly (multimedia application), load isolation using currencies work fine (adding new tasks to B does not put a dent in the fair share of tasks in A ). They also showed the working of their ticket transfer idea using a client-server application.

5. Confusion
How do they perform trade-off in a multi-resource environment? Also who is responsible for assigning tickets?, how can the nice system call be implemented in such systems?

1. Summary
This paper presents a randomized resource allocation mechanism, lottery scheduling. It is a proportional-share and flexible scheduler with excellent support for modular resource management. The same principles are easily extended to manage many diverse resources, such as I/O bandwidth, memory and access to locks.

2. Problem
Current methods to support responsive execution rates of computation that are relatively flexible rely upon a simple notion of priority. They are not understood well and often implement ad hoc schemes to adjust priorities. Existing fair scheduler provide a coarser control over long running computations not suited for interactive applications.

3. Contribution
The main contribution of this paper is the idea of a simple and flexible means of controlling the distribution of resources among competing processes. It is straightforward to understand the fairness of this proposed scheduling scheme for long running application. The simple ticket based mechanism makes it possible to implement many useful advanced features. Ticket transfers during RPC helps ensure that the client is not blocked for an unfair amount of time. The concept of ticket currencies helps to enforce the isolation needed in a fair scheduling policy. Processes which use less than the available time slice are sufficiently compensated to ensure a fair scheduling policy. The idea of lottery scheduling applied to manage resources other than compute resources, such as lock contention, and space-shared resources is very interesting and easily implementable.

4. Evaluation
They implemented a lottery scheduler by modifying the Mach 3.0 microkernel. The authors evaluate the fairness of the system by showing that the relative runtimes of two applications is proportional to the number of tickets allocated to them. They show the use of lottery scheduling to maintain fine-grained and dynamic control over process scheduling by running monte carlo simulations that start at separate times and request tickets proportional to the error rate of the current iteration. They also evaluate load isolation by showing that the ratio of execution times of two tasks remain the same even though new threads with different ticket shares are created within these tasks. The client server applications verify the validity of the ticket transfer mechanism while the multimedia applications experiment shows that their scheduler maintains fairness in a scenario where prior work has found it difficult to guarantee it. Although, they do measure system overhead, I would have liked to see a comparison of this scheme with a popular scheduling scheme of that era. It would have been wonderful to see some numbers validating the compensation scheme and experiments that look into a potential system throughput implication of such a scheme. I also found it difficult to precisely interpret the response time for interactive applications from the data provided.

5. Questions
1. The section on Multiple Resources was not clear.
2. Why are multimedia applications evaluated separately?

1. Summary
This paper presents the design of a lottery-based generic scheduling algorithm for managing system resources. The design tackles the weaknesses of existing solutions to provide an efficient, lightweight and flexible mechanism that not only achieves proportional resource allocation, but provides modular resource control and can be extended to manage diverse resources.
2. Problem
Allocation of shared resources among multiple processes/users is a desired feature in system design. Existing solutions like priority-based systems did not provide modularity and flexibility required to support complex softwares systems. Other systems like fair-share and microeconomics schedulers provided only coarse-grained control and were effective only for long running computations. They were too complex with highly complicated dynamic priority control mechanisms and suffered from other issues like positive feedback loops. Dynamic lightweight scheduling control, the kind required for interactive latency-critical applications, was lacking. Lottery scheduler aims to provide a generic, flexible and responsive resource management.
3. Contributions
The design uses abstraction of tickets to guarantee probabilistic fairness. Mathematically, the paper shows that an entity holding large number of tickets gets proportionally high access to resource and has proportionally low response time. However, the biggest contribution was that the simplicity of this design allows a number of mechanisms that enhance system performance while maintaining fair resource allocation and make the resource management more modularised than ever. Ticket transfer helps increase system performance by allowing the bottleneck thread to execute faster and unblock the dependent threads. It also solves the problem of priority inversion. Ticket inflation is quite effective when the user manages a set of mutually trusting clients. The most innovative, yet simple, feature of design in my opinion was the concept of currencies. It enabled insulation between users/groups so that the resource control at the local level does not impact the rest of the users/groups. This is makes it easy to use other mechanisms like ticket inflation/deflation to manage the resources locally quite efficiently. Lastly, compensation tickets allow IO bound applications that yield the CPU without using their allotted quanta, to still enjoy their share of resource usage.
4. Evaluation
The authors have evaluated the design using compute-bound Dhrystone benchmark, Monte-Carlo programs, multithreaded client-server applications and MPEG video viewers. Through multiple experiments it has been shown that lottery-scheduler is able to achieve the desired proportional resource allocation. Using monte-carlo simulations, they have shown how ticket inflation/deflation is effective in dynamically adjusting the shares for specific goals. Using custom client-server benchmarks, the efficacy of ticket transfer mechanism has been shown. The authors attempted to demonstrate how their design solves the problem of diverging resource shedding due to positive feedback loop while managing multiple multimedia applications in previous schemes. However, the results presented are not convincing and more experiments/explanations are required for better understanding. The experiments studying system insulation are very impressive. They clearly show how one user group is completely cut-off and protected from what happens in a different user group. In the end, authors show that lottery implementation in Mach kernel did not impose any major overhead compared to the default scheduler implementation.
The biggest flaw in the evaluation is that no quantitative comparison against other schedulers has been made (except overhead). For example, response time for short applications was one of the goals of the work and should have been evaluated by comparing against other systems. Ticket compensation seems like an effective idea but has not been evaluated at all. I am also not sure about the choice of benchmarks - running more mainstream workloads would be interesting to study resource management and system performance. It would help authors present a stronger case if they run some IO bound applications as I believe system performance should be much better with lottery-scheduler.
5. Confusion
The authors discuss multimedia application like a special case and we observe that the results with video viewers are not very convincing. What is different about multimedia applications compared to other workloads as far as scheduler is concerned?
The design seems to make sense for closed systems like a shared system with multiple users in an organization. Does it make sense for in-the-wild systems like personal computers?

1. summary
This paper is about lottery scheduling which is a randomized resource allocation mechanism which provides efficient and responsive control over process execution by manipulating the currency and number of tickets held by a client.
2. Problem
Resources have to be multiplexed to service requests of varying priority and functions while minimizing impact on throughput and response time of the system.The existing scheduler mechanisms that support flexible control rely on priority and do not provide encapsulation and modularity. Further, existing fair share schedulers are limited to provide coarse grained control over long running computations and can have issues like priority inversion.
3. Contributions
Resources are allocated to competing clients based on the proportion of lottery tickets they hold.The allocation mechanism is probabilistic-ally fair since any client with a non zero number of tickets will eventually win a lottery therefore the problem of starvation is avoided.Ticket transfers allow clients blocked on a server to temporarily transfer their tickets to the server on which they are waiting. This solves the priority inversion problem. Ticket inflation/deflation is another way in which tickets can be transferred between mutually trusted clients, a client can escalate/de-escalate its resource rights by creating/destroying tickets.Ticket currencies are used to implement abstraction barriers across logical trust boundaries.Further,if a client consumes fraction of allocated resources it is granted a compensation ticket.
4. Evaluation
The accuracy with which the prototype can control relative execution rates of computations has been highlighted.It is shown that variance is greater for greater allocated ticket ratios.Its behavior over a shorter and longer time have been evaluated.Thus the evaluation of fairness is nuanced and thorough.Further the flexibility in control is highlighted by showing that by adjusting an experiment’s ticket value as a function of its current relative error it is possible to approximate results quickly for new experiments and slower for older experiments(Monte Carlo experiment).By modifying the Mach IPC primitive to support temporary transfer of tickets ,the client server model has been evaluated to highlight client server ticket sharing.Overall, the overhead of this implementation is comparable to that of the Mach kernel. Though the paper mentions optimizations that can be implemented to reduce this overhead they do not theoretically(or empirically) discuss (or prove) how these optimizations could reduce the overall overhead.
5. Confusion
Can compensation tickets be used game the scheduler ? would be useful to go over how compensation tickets function.

1. Summary
Lottery Scheduling is a scheduling mechanism that achieves responsive and flexible proportional-share of resources with probabilistically fairness by replacing priority with more meaningful concepts of tickets and currencies.

2. Problem
Multiplexing scarce resources with relative computation rates for requests of different importance has been a challenging problem. Existing solutions use a poorly understood notion of priority and the system built is complicated, slow and inflexible.

3. Contributions
Relative tickets are used instead of absolute priority. The probability that a ticket is selected to win gets adjusted implicitly when other tickets are activated or deactivated. This makes the scheduler extremely responsive.
Tickets can be transferred on a synchronous RPC call. Clients with more tickets are able able to fund their server threads with more resources, which help achieve lower response time and higher throughput.
Flexible modular resource management is made possible by maintaining a currency acyclic graph. A currency is funded by tickets of more primitive currencies and can distribute its own tickets. This gives a client the ability to divide its tickets to multiple servers without affecting other clients, as inflation is contained in its own trust boundaries.

4. Evaluation
The authors evaluated lottery scheduling with respect to fairness, responsiveness, effectiveness of ticket transfer and modular management, and overhead.
The fairness experiment is done by running two compute-bound Dhrystone benchmarks with relative ticket allocation and comparing their iterations over short or long time intervals. Results show the average iteration ratio is close to the ticket allocation. A similar experiment is done for three MPEG video viewers, but the ratio of frame rates is distorted by the round-robin scheduling inside X server. Frame rate ratio with ‘-no-display’ turned on matches the ticket allocation.
They show the ability to dynamically adjusting the proportion by running the Monte-Carlo algorithm. By setting the ticket value as a function of current relative error, a job with larger error gets more time to run and catch up quickly. This idea is interesting but as conventional schedulers cannot do this, no comparison is done.
They developed a simple client-server application where server relies fully on the tickets passed from clients. Both ratios of number of queries processed and response speed is close to the clients’ allocation.
Modular management is tested by running two groups of Dhrystone benchmark tasks. Starting a new task in the group B has negligible impact on the tasks in group A.
The overhead evaluation is the only part that contains comparison. Numbers of iterations of Dhrystone benchmark tasks and completion time of client-server application with 20 queries are compared between lottery scheduling and round-robin Mach.
To make the evaluation complete, overhead of ticket and currency management should also be measured. What is the overhead incurred by transferring ticket when doing a RPC? How well do compensation tickets work? Also, comparison should be done against fair share schedulers and microeconomic schedulers.

5. Confusion
When a RPC request is sent and there is no server thread waiting, the author provides two options: to wait on a list or to fund all threads. It seems both option would violate the fairness requirement.

1. Summary
The paper introduces a general randomized proportional-share scheduling algorithm- Lottery Scheduling. The basic concept is that of a ‘ticket’ which represents the share of the resource that a user should receive; more the number of tickets user possesses, more are its chances of winning the resource(lottery). The paper discusses how lottery scheduling supports modular resource management and how it can be generalized to manage many diverse resources.
2. Problem
Problems with traditional schedulers are that they are complex and difficult to control. Priority systems cause starvation: highest priority always wins and system knows nothing about users as scheduling is done based on processes thereby users with less processes starve. The algorithm of fair share is implemented by adjusting priorities with a feedback loop to achieve fairness over a (very) long term- highest priority still wins all the time.
3. Contributions
Randomized approaches provide simple and robust decision making. In lottery scheduling, priority is the relative percentage of all of the tickets whose owners compete for the resource, scheduler picks winning ticket randomly, and gives owner the resource. Random approaches require less state-keeping, hence they are lightweight. However, a deterministic approach gives more accurate proportions, especially over short time scales.
‘Tickets’ represent the user’s share of the resource(s), they can be used for a wide variety of different resources (uniform), are machine independent (abstract) and winning depends on contention level(relative). So, ticket is a powerful way to express the proportion of resources. This algorithm allows ticket inflation to adjust allocations wo/ communication, assuming the users are mutually trusting. It is easy to donate resources (ticket transfer) when a process is blocked due to a dependency: works well in a client-server model where server with no tickets, gets all its clients’ tickets and cumulative priority, thus eliminates employing priority inversion. With currencies, user managing multiple threads can favor some threads over others without impacting the threads of other users. Compensation tickets makes the system fair towards I/O bound and interactive processes. The paper shows this algorithm being fair as the allocations increases.
This scheduling algorithm employs powerful mechanisms of randomizing and proportional- sharing. However, it suits only those domains where assignment of shares is easy, like a hypervisor allocating resources to the VMs.
4. Evaluation
It is implemented on a MIPS-based DEC station running Mach 3 microkernel. Requires a fast random number generator and a fast way to pick lottery winner. They present a set of experiments to evaluate flexibility, responsiveness and efficiency of lottery scheduling. Allocations over short time scales have some variations but for larger time scales, it approaches the exact proportion ratios as seen with CPU intensive (Dhrystone) workload. Monte Carlo problem computation makes use of the responsiveness of the scheduler by dynamically controlling ticket value according to the relative error. An experiment of multithreaded client-server shows the flexibility to transfer tickets when blocking on server. Load insulation evaluation shows that currency management does not transcend trust boundaries. It also manages diverse resources like locks/space-shared resources.
Evaluations could have been richer by measuring the responsiveness for a mixed interactive and CPU-bound workload, calculating overheads of scaling processes(scanning through ticket list) and threads(computing long currency trees), trying on different architectures/kernel to test the abstract nature of tickets, their transfers and priorities.
5. Comments/Confusion
How does it estimate the number of tickets to be assigned to a user? Would it assign a default proportion of current resource(s) to the new user process and then re-assign priority overtime or is there a way to decide on priority policies(~shares) between user/process and scheduler upfront?

Summary
This paper presents lottery scheduling, a randomized resource allocation mechanism that dynamically handles changing resource requirements in a simple and efficient manner. Lottery schedulers are capable of providing modular resource management by representing resource rights as lottery tickets. Lottery schedulers can also be used for allocating any resource which requires queuing for resource access.

Problem
Existing scheduling policies, such as priority schedulers, fair share schedulers, decay-usage schedulers, microeconomic schedulers or schedulers using market-based approach for memory allocation, did not adequately provide the necessary support for modular (fine-grained) resource management between entities contending for the given resource, which prevented resource usage with relative rates of consumption. They were also found lacking in providing simple and efficient ways of dynamically scheduling the underlying resources according to the changing resource requirements of the entities using these resources. What was required was something like a statistical matching technique used for fair switching in the AN2 network which used randomness to dynamically handle changes in resource allocation.

Contribution
Lottery tickets are the abstract, relative and uniform encapsulation for resource access rights. Each allocation of a resource is determined by holding a lottery, which is probabilistically fair. The lottery mechanism allows a client's throughput and response time to be proportional and inversely proportional respectively to its ticket allocation. Lottery winners can be determined using the list-based lottery with 'move to front' heuristic with the running ticket sum maintained in base currency. Modular and dynamic resource management is obtained by using techniques such as ticket transfers, ticket inflation, ticket currencies and compensation tickets.

Ticket currencies are resource management abstraction barriers that locally contain intra-currency fluctuations such as inflation and flexibly isolate or group users, tasks and threads. Each currency maintains an active amount sum for all of its issued tickets. Also, a currency's funding value is computed by summing the value of its backing tickets, while ticket values are the product of its currency value and its proportion of active tickets issued in that currency. Compensation tickets allow a task that uses only a fraction of its allocated share quantum to receive its entitled share of the processor. Ticket transfers are achieved by using newly created client tickets to fund a server's currency.

The lottery scheduler also ensures fair and efficient resource allocation when resources need synchronized access, by using a lock funding mechanism on a lottery-scheduled mutex. Space shared resources such as memory can also be managed by a lottery scheduler by using an inverse lottery method to determine the victim page for swapping out to disk. Manager threads can be associated with applications to abstract evaluation of resource management options.

Evaluation
The authors conduct various experiments to demonstrate the viability of lottery scheduling. A prototype of a lottery scheduler was first implemented by modifying the Mach 3.0 micro-kernel. This implementation provides a command line interface for ticket / currency creation / destruction and currency funding / unfunding operations. They then evaluate the following aspects / scenarios of lottery scheduling - 1. Fairness of resource usage given a varying ticket allocation ratio between two identical tasks 2. Flexible control of resource allocation by using dynamically controlled ticket inflation. 3. Effectiveness of ticket transfer mechanism in a client-server computation setting, where the client transfers tickets to the server when it is blocked for the server response. 4. Demonstration of the viability of scheduling multimedia applications fairly and reliably on the lottery scheduler. 5. Load insulation by achieving ticket reallocation which is localized to a specific currency. 6. Measure system overhead against an unmodified Mach kernel for Dhrystone benchmarks and a multi-threaded database server. 7. Fairness of resource sharing in scenarios requiring inter thread synchronization to check effectiveness of lock funding mechanism.

In all of the above evaluations, the lottery scheduler performed along expected lines and was able to demonstrate its properties of fairness, dynamic resource allocation, comparable overhead and load insulation. The evaluation discusses possible optimizations that could have been added to the currently unoptimized lottery scheduler implementation. However, these suggestions have not been backed up by a profiling analysis of the lotter scheduler overhead. If profiling were to be done, we may observe different aspects of the lottery scheduler implementation to be actually causing the bulk of the performance overhead, than those predicted by the authors. Also, as all overhead tests were against an unoptimized lottery scheduler implementation, we are unable to predict the true performance potential of this approach.

Questions / confusion
1. It was not clear how the authors implemented the lottery scheduler on Mach while also allowing it to co-exist with other timesharing and fixed-priority policies. Specifically, how did they choose what scheduling policy to use at a given instance of time?
2. Is lottery scheduling being used today in popular systems? If no, what drawbacks prevented its widespread adoption?

1. summary
Lottery scheduling, a randomized resource allocation, uses these primitives, lottery tickets and winning ticket, to provide each tasks with fair system resources and quality of service. The resource allocation is randomly determined by tickets a client hold and its evaluation show that the allocations are almost same as a ticket rate a client has.

2. Problem
The resource should be multiplexed efficiently for executing important and urgent work with high priority because it affects the throughput and response time. In addition, the program should be controlled properly based on its runtime and how much important the response time is. Few general purpose scheduling policy does not provide the service quality, which schedule the job upon fairness, due to the lack of encapsulation and modularity properties.

3. Contributions
The main contribution in this paper is how to judge next task. The paper said probability is the best choice for fairness because if each tasks hold their tickets and choose a ticket randomly, there is no task starving.
Their allocation time for resource is defined by relative shares being allocated, provides responsive control over the relative execution rates of computations. This policy is supported by lottery tickets representing resource right and randomized scheduling algorithm. The tickets are inflated based on runtime while its usage is not evaluated. When a client requests the job to be executed on a server, the tickets are transferred to servers so that the allocation rate does not changed.

4. Evaluation
They used many method to evaluate their work. First, they evaluate their fairness to give same tickets to two clients and then observed the allocation iteration with 2:1 ticket ratio. And then they evaluated lottery scheduling on various priority using monte-carlo and transferring tickets between a server and clients using database server system.
The paper idea is straightforward so they seemed to focus on evaluating their work. The evaluation section contain many experiment resultㄴ while I think some of the evaluations such as multimedia are redundant, which said same results again and again. Because I don’t feel that we should evaluate all the applications, which can obtain benefits from the work. I think it seems to need data structure to hold the information of ticket and values while the memory usage is not explained. In addition, they did not evaluate compensation ticket policy.

5. Confusion
What is the meaning of encapsulation and modularity properties in the paper?

Summary
This paper describes lottery scheduling, a general purpose proportional-share scheduling based on the notion of lottery. It provides efficient,flexible and responsive control over the relative execution rates of computations.

Problem Statement

The existing traditional schedulers are often complex and difficult to control. They don't address responsive control over service rates properly and efficiently. Few of them rely on priority to service requests of varying importance. However, priority assignments are often ad-hoc where highest priority always wins. Fair share schemes adjust priorities with a feedback loop to achieve long term fairness but still highest priority wins. Also, there is the problem of priority inversion where high-priority jobs can be blocked behind low-priority jobs.

Contribution

In lottery scheduling, resource rights are represented by lottery tickets. Tickets are abstract (machine independent), relative (chances of winning lottery depends on contention level) and uniform (can be used for a wide variety of different resources). Priority is determined by the number of tickets each process has and each allocation is determined by holding a lottery. Scheduler picks winning ticket randomly and the client having the winning ticket is granted the resource. This type of scheduling by lottery is probabilistically fair as the expected allocation of resources to clients is proportional to the number of tickets that the clients hold. As all the clients have a non-zero number of tickets, the problem of starvation never arises. The tickets can be transferred from one client to another whenever a client blocks for some dependency thereby solving the priority inversion problem. Ticket inflation/deflation can only happen among mutually trusting clients and allows to dynamically change the priority without explicit communication. The tickets can be expressed differently for different groups and hence currency can be used to denominate tickets within each group. This allows each group to handle its own resource allocation without disturbing other group's allocation. A client that consumes only a fraction of its allocated resource quantum can be granted a compensation ticket thus ensuring that each client gets its fair share of the resource. Compensation tickets favor I/O bound and interactive threads as they can regularly block.

Evaluation

The authors evaluate lottery scheduling by running compute bound benchmark, Monte-Carlo numerical integration program, multi-threaded client-server application for searching text and multimedia application. Mostly in all of the applications, the observed ratios are close to the corresponding original allocations showing that lottery scheduling can control the relative execution rates of computation. Using the Monte-Carlo application, they show that lottery scheduling can be used to allocate more share of resources to one task while other tasks can be allowed to make slow progress. Overall, the experiments show that temporal fairness can be achieved by lottery scheduling however, instantaneous fairness is not guaranteed. In the experiment involving multimedia application, the observed ratio is not same as original ratio showing that there can be a secondary force(X server) that can impact the priority. The authors show that lottery scheduling can be used for managing diverse resources by using it on Synchronization resource(mutex).
However, it would have been nice to see the memory overhead numbers as the number of tickets increase. What would it look like when there are billions of tickets? Another missing point is to understand how lottery scheduling works when compute bound applications run along with applications that block regularly? Do we still observe the ratios same as original allocation? Is there a penalty to pay due to broader/deeper currency graph in such scenario?

Confusion
How does the scheduler handle the ticket numbers when process gets added or exits? Wont the process that exits create a hole in the sequential ticket numbers? How are shared services handled where one process wants the shared service to run with higher priority while another process wants to run the same service with lower priority?

1. Summary
In this paper, the authors introduce the concept of “lottery scheduling”, in which processes hold “tickets” and are allocated resources according to a random number generator. The paper details the basic process as well as several applications for which it can be used.

2. Problem
Scheduling resources is a complex task in multi-threaded systems, and few general-purpose schemes can support flexible control over service rates. Existing fair share schedulers are also limited to relatively coarse control over resources. Lottery schedulers, on the other hand, is a randomized scheduler that implements “proportional-share” resource management. It is probabilistically fair and can be applied to a variety of situations.

3. Contributions
Essentially, a ticket = one share of a resource right, relative to the total number of tickets issued. Tickets are a representation of resource management for processes, and they can be inflated, pooled, or traded away. The main characteristics of lottery scheduling are:
(1) Lightweight: a tree-based lottery needs to only generate a random number and perform log n additions/comparisons to pick a winner.
(2) Fairness: Over multiple runs, lottery scheduling works out to match the proportion of tickets a process holds.
(3) Synchronization: critical area contention can substantially affect computation rates, but lottery scheduling can control the waiting times. Blocked threads transfer their tickets to fund the mutex, and the winner then takes control of all the tickets. This allows the mutex owner to execute as quickly as possible. When done, the mutex is yielded along with the tickets that it previously controlled.
(4) Inverse lotteries: the lottery idea can be repurposed to force processes to yield resources. Essentially, a “winning” ticket has to relinquish control of a resource.
(5) Flexible control: Ticket values can be dynamically adjusted, thus dynamically changing the value of resources held by a process at any given time.
(6) Multiple resources: the evaluation of resource management can be abstracted into “manager” threads for each application. This can then make decisions on funding for different resources and reallocations.

4. Evaluation
They implement their prototype on the Mach 3.0 Microkernel. They also developed a simple multithreaded client-server application that can be used to test ticket transferrence and responsiveness. In testing, they looked for three aspects: fairness, flexibility, and responsiveness. In fairness, the observed ratios are generally very close to the corresponding allocations for each process. In control, currencies can be adjusted to allocate different proportional amounts depending on some criteria. The example they use is Monte Carlo tasks, with the control variable being error rate. Finally, for responsiveness, they used the client-server model in which server time is funded by the requesting clients' tickets, which can affect response time and throughput. They show how this can be used to affect priority for clients wanting to reach a common resource such as a database or server.
Things I would have liked to see: what is the exact overhead per tick for each random number generation and selection? Also, how are tickets issued? What is the deciding mechanism for the exact proportion of tickets each process gets?

5. Confusion
What exactly is a ticket currency that is “funded by tickets that are denominated in more primitive currencies”? I understand the general concept of currencies, but that sentence confuses me.

1. Summary
The paper presents a new mechanism for scheduling: lottery scheduling. Lottery scheduling provides flexibility, but it also removes overhead of previous schedulers, making it much more responsive.
2. Problem
The authors found schedulers at the time to lack the throughput and response time needed to multiplex scarce resources. They found that many systems, especially the interactive systems, needed fast and dynamic control over scheduling.
3. Contributions
To address these issues, the authors propose lottery scheduling, where each process is given a number of lottery tickets (based on how important they are), and the processes compete with each other to win the lottery to get access to a resource. Having more lottery tickets gives one a higher chance of winning the lottery.
Because of this added randomness, it is very fast to find a winner and schedule them, so the overhead of choosing a process that deserves to run next is greatly reduced. As a result, over time, each process gets the correct amount of time they deserve based on the number of tickets they have.
Three contributions build on top of this concept:
1. lottery tickets are transferrable: if a client performs an RPC call to a server, it can temporarily give its tickets to the server, so the server will have a higher chance of running. Hence, the client will have a higher chance of faster response.
2. Tickets can have different currencies, and this can create a hierarchy of ticket currencies. At each level, a parent can decide how to split its tickets amongst its children in a new currency.
3. The concept of lottery scheduling can be applied to any other resource other than scheduling, such as I/O bandwidth, memory access, and access to locks.
4. Evaluation
The authors tested all the features of lottery scheduling, not just the performance of the system. They measured the fairness, flexibility, ticket transfer through client-server communication, ticket currency, and system overhead. For example, in the fairness test, they showed how much time was allocated to processes with different ticket numbers, and they showed that the ratio is relatively close to perfect situation. The ratios are not perfect because of the randomness of the scheduler. It is true that lottery scheduler is much more flexible and continues to be fair, but the authors also claimed that their scheduler will have much more throughput, however, they show that their performance is very close to the standard Mach timesharing policy. They also do not really go into more details about how these tickets are allocated to processes. They mention the concept of managers for each thread, but the overhead of managers is not evaluated.
5. Confusion
How are priorities given to different processes today? Are they manually entered by system administrators? Is there a system that recognizes client’s dependence on a server process, thus increasing server’s priority?

1. Summary
The paper presents a randomized approach to resource allocation called Lottery Scheduling. This approach is easy to implement, supports modular resource management and provides a more responsive control mechanism over the relative execution rates of the computation. The paper also shows how Lottery Scheduling can be generalized to manage diverse resources.

2. Problem
The available resources for programs are regulated using the traditional priority schemes. These priority mechanisms only offer coarse grained control. Priority assignment and dynamic priority adjustment schemes are ad-hoc except for the hardcore real-time systems. Even popular priority based schemes like decay-usage scheduling are poorly understood and achieving specific results with these scheduling schemes is considered black art.

3. Contributions
The key contribution of this work is presenting an abstract, relative and a uniform approach to represent resource rights instead of the traditional priority based mechanism which uses absolute priority values to allocate resources. The ticketing approach is abstract as it can represent resource rights irrespective of the underlying machine, it is relative as the fraction of resource it represents can vary dynamically depending on the contention and it is uniform because it can homogeneously represent heterogenous resources. These characteristics make lottery scheduling suitable for representing numerous resources like CPU time, physical page allocation and synchronization primitives. Lottery scheduling is probabilistically fair, which implies that it can be formally proved that they do not cause the conventional problem of starvation. Lottery tickets can be transferred and so they can also solve the priority inversion problem if the blocked thread can transfer its tickets to the thread on which it is waiting. Operations on ticket currencies can be used to exert fine grained control over the managed resources between mutually trusting clients.

4. Evaluation
The authors claim that the Lottery Tickets are abstract, relative, uniform. They demonstrate how they are relative using multimedia applications and the uniformity is demonstrated by managing diverse resources like CPU time in Monte-Carlo, client-server simulations and synchronization resources. To support Ticket Scheduling on a machine, it is required that it allows to implement an efficient pseudo-random number generation algorithm, so to strengthen their claim of abstraction, I feel they should have shown how this core routine can be implemented on other architectures prevalent that time. The fact that Ticket scheduling is relative means that the algorithm has to adjust the fraction of resources the tickets represent dynamically when a new application is spawned or when a current application asks for more tickets or discards its current tickets, this balancing looks like an overhead and it would have been good to see an evaluation of how the system behaves when there are a lot of processes which are continuously evolving like in the case of a mutli-user system with a lot of users logged in.

5. Confusion
Can we discuss how much work a lottery scheduler has to do each timer tick and if it is possible to use it on systems which use very high ticks/sec?