CS 736 Reviews - Spring 2015

Summary - This paper describes the philosophy of separating mechanism from policy which was followed in the design of the Hydra system. The authors discuss the implications of this design principle to process scheduling, paging and protection by presenting the mechanisms provided and the means to implement external policies.
Problem - The authors are primarily concerned with the problem of creating a flexible operating system by letting user level applications guide the resource allocation policies enforced by the operating system. The key issue is determining an effective set of underlying mechanisms to be implemented in the kernel, and the level of control provided to the user programs.
Contributions - The main contribution of this paper seems to be the notion of separating operating system policy from mechanisms to create a versatile operating system. The authors advocate implementing certain basic mechanisms in the kernel, which can be used by user programs to guide policies of process scheduling, protection,etc. The idea of parameterized policy is an important one to limit the extent of user choice to safe and tested alternatives. An important takeaway is also that the kernel must possess some means of enforcing fairness between the resource allocation policies of various programs.
Evaluation - There is no evaluation done for the ideas in the paper, and the authors haven’t implemented their ideas fully.

1. Summary
This paper put forward the idea of a separation of policy and mechanism in Hydra, and shows its application in various dimensions such as process scheduling, paging, and protection.

2. Problem
Existing design of operating systems aims to let the users better utilize the hardware facilities while keeping the operating itself safe and secure from users’ intentional or unintentional abuse. Therefore, we need to give control to user-level software while restrict some undesired scenarios in the kernel. Policies are user-level software that manages some resources via communicating with kernel, while mechanism is implemented in the kernel to ensure such resource management is safe and fair.

3. Contributions
The solution of policy/mechanism separation comes from the compromise between better utilization for the user and appropriate protection for the system. The mechanism implemented by kernel operates the hardware or itself is a parameterized policy. The concept of mechanism and policy is relative to each other.

In scheduling, KMP has PMs which manages processes in its possession. PMs set the scheduling policy via PCB and KMP provides several mechanisms to start/stop processes and set/get PCB, as well as set/receive policy configurations. On execution, KMP implements a time-sharing system to each PMs, and each PMs could schedule its processes dynamically in this time slice.

Paging technique. Each process has a three level paging system LNS/CPS/RPS, each being a subset of page frames of the precedent. Paging mechanisms include loading CPS/RPS page. Paging policy is closely couple with scheduling. When a process starts executing, CPS pages will be brought to primary memory and when it stops, all pages related are eligible to be replaced. Each PM has a guarantee of page frames but page sharing and under utilization may cause inefficiency. Page replacement is done by priority eviction assisted by LRU. The work is mainly left to kernel because PMs know little about paging information.

Protection sticks to the policy/mechanism separation the best. PM will control the accessibility of processes and a negotiation among PMs is implemented in the kernel to ensure fairness and exclusive control.

4. Evaluation
Although this paper did not provide numerical evaluation, I think it did well in making its point and address the solution because 1) it provides several choices in making decisions, 2) it explains the strength and weaknesses of each choice and make final decisions accordingly, and 3) it even points future improvement may change the decision. A simple example is whether or not to disclose paging information PMs. It explains the inefficiency and safety problems with PM notification on every page replacement while saying faster hardware might over turn the optimal choice.

5. Confusion
The paper spend quite a bit length in describing page replacement policy, especially the one based on priority scores and LRU. However, in my point of view, calculating/sorting these priorities may consume more time than simply implementing random page replacement. It seems the benefit from an optimal selection of page eviction may not compensate the time and computation resources it costs. Did authors think about this?

1. Summary
This paper talked about the philosophy and design details of the principle of policy/mechanism separation brought up in Hydra system. Specifically, the paper discussed the policy/mechanism separation implemented in multiprocess scheduling, memory paging, and system protection.

2. Problem
In Hydra, policy/mechanism separation was one of its basic design principles. However, for different mechanisms, problems exist for mechanisms and policies to work together when people try to apply the policy/mechanism separation principle in system design to provide user-level flexibility.

3. Contributions
This paper designed three sets of solutions in detail to shed light on possible designs with policy/mechanism principle. Namely, the kernel multiprocessing system for process control and scheduling, paging for memory use, and the protection system.
With KMPS, the policy is actually a parameterized mechanism which allows user flexibility in scheduling.
In paging, the replacement policy is handled in the kernel in order to achieve efficiency and protection in the system design.
As for protection, Hydra provides clear seperation of mechanism and policy. This paper added some discussion on negotiation between a process and the PM.

4. Evaluation
The paper presented its system deisgn philosophy and detailed implementation without comparison with other similar systems.

5. Confusion
In the hydra paper it brought about the idea of rejection of strict hierarchical layering, isn’t it different the design of modern OS? Was it a bad idea that has been abandoned in later system designs?

1. Summary
This paper describes the design philosophy behind the HYDRA kernel that the mechanism must be separated from policy. The kernel is composed of mechanisms while leaving the implementation of policies to the user-level software. This allows a great deal of flexibility in the operating system. The paper presents 3 examples of scheduling, paging and protection to illustrate how this design philosophy has been adapted. The paper also reasons out why at certain places some policies are embedded in the kernel to ensure fairness and for conflict resolution.

2. Problem
Policies are a major dimension of operating systems that contribute to its variability. The other systems that existed at that time did not allow control over these policies to user-level programs. They did not suit some special cases that were important to the authors. Thus, by allowing control over these policies like resource allocation, security, etc., it allowed each user to tune the system for their own needs and co-exist with users with varying needs.

3. Contributions
The major contribution of this paper has been its design philosophy. The mechanisms and policies of an operating systems are separated. The kernel which forms the core provides an adequate set of mechanisms. Where as, the policies can be implemented by user-level programs via mechanisms provided by the kernel based on its requirements and communicate with the kernel. This allows the use of the kernel to build system that suits varying needs rather than a specialized need. This was new considering the fact that at that time, it was common to have different operating systems for specialized applications.
The paper also mentions that at many instances, the system does compromise on the design philosophy and some policies are built into the kernel so as to guarantee fairness and conflict resolution among competing policies or to ensure better performance. Thus they did not stick to the same philosophy and hence designing a hybrid system with the mechanism/policy separation as the base.
Some kernel mechanisms are a parameterized policy. This provides a means by which long-term policies can be enforced by the user-level programs, and at the same time avoiding delays during domain-switching for decisions that must be made rapidly.
The above ideas have been demonstrated through the use of KMPS and PM for scheduling, and the use of a sort of memory hierarchy of LNS, CPS and RPS for paging; and finally a complete separation that could be achieved for protection.

4. Evaluation
Many parts of the system were not completely implemented at the time of this writing. Hence, the author presents no quantitative evaluation of the system. However, the author presents 3 examples of scheduling, paging and protection to back the design philosophy of the system.

5. Confusion
I was confused where some abstractions are presented in the paper like the policy module (PM). Is this idea of associating every process with a user-level scheduler like the policy module prevalent in the existing operating systems. How are multiple processes grouped under a single policy module and whose responsibility is this?

1. summary
The paper discusses the separation of mechanism and policy in Hydra and examines the principle in scheduling, paging and protection.

2. Problem
The Hydra system is aimed to enable the construction of operating system facilities as normal user programs. However, the program can intrude several ways, including malevolent program, monopolizing resources. Besides, policy decisions must be made rapidly.

3. Contributions
The paper shows the application of the policy/mechanism separation principle in KMPS, paging and protection.
(1) KMPS implements a mechanism to support policies for scheduling user processes. A user-level scheduler is called a Policy Module. The relationship between process and PM is many-one mapping. KMPS guarantees the error of one PM will not effect others. A policy object acts as a message mailbox between kernel and a PM. The scheduling is based on priority, processor mask, time quantum and maximum current pageset size. To support multiple scheduling policies simultaneously, each PM is allocated a "rate guarantee" for CPU cycles.
(2) A user program is capable of referring specific pages using LNS information. Each active LNS is associated with a CPS and a RPS. RPS, CPS and LNS define a three-level memory system. The page frame allocation and io transfer initiation is in CPSLOAD and program will not be suspended until RRLOAD. Only CPS associated with its current needs to be core-resident. Each procedure object contains information about the initial CPS/RPS configuration to be associated with a LNS. Page is handled by the kernel, which can tightly couples paging and scheduling. Each PM is guaranteed a specified number of page frames. Each replaceable page is assigned a priority (modeled by cost function) and replacement is done in reverse-priority order and then lru order. The page mechanism is also influenced by the hardware architecture.
(3) Hydra protection structure provides a clear separation of mechanism and policy. Hydra supports selective access to information. PM cannot gain access to any capabilities or data in the process and an LNS has little control over the PM. Each policy object includes information for the trustworthiness and reliability of a particular PM, which can only modified by "system administrator". The kernel also allows negotiation between a process and its PM.

4. Evaluation
The paper doesn't give much evaluation. Some of the work is even just under simulation.

5. Confusion
I think the scheduling mechanism is very rigid. The paper also mentions that it's difficult to share pages between different PMs and each PM can be guaranteed a specific number of page frames. I think most of the time some PMs can have enough resources but some may always be starving (What if a PM has many processes and the other just has very few). So we should also have a mechanism to equally divide processes to PMs? This needs more information and is more difficult.

1. Summary
The paper, describes HYDRA’s design philosophy of separation of policy and mechanism by entrusting certain resource allocation policies to user-level programs and leaving low-level mechanisms to the operating system’s kernel. It discusses three mechanisms - scheduling, paging and protection where this separation helps HYDRA to have a flexible operating system allowing user-level control of policies.

2. Problem
Previous and extant operating systems had all the facilities buried deep into the systems kernel, making the OS structure rigid and inflexible, and often failed to work well in special cases. The user programs still had to always rely on a heavy kernel to implement new adaptations and tunings, abiding to the protected execution environment insulation provided by OS. The authors in the paper, have addressed this problem by allowing some policies to be defined at user-level by taking support from the lower-level mechanisms provided by a light-weight kernel.

3. Contributions
a) Scheduling: The sanity of user-programs not directly accessing the hardware resources is still provided by the kernel exposing some interfaces (mechanisms) through a parameterized policy called Kernel Multiprocessing system. A user-level process scheduler called Policy module is responsible for starting/stopping and scheduling user processes. KMPS assures fairness among various competing user-level policy programs by using a guarantee algorithm, and thus provides needed flexibility to the system. Policy objects are used as communication points between KMPS and PM, for some short-term scheduling decisions.

b) Paging: New abstraction of LNS, CPS and RPS is provided to efficiently use shared primary memory page frames. Mechanisms for user program capabilities, to swap in and out core page objects corresponding to current LNS/top CPS is given. A paging policy to keep page objects of top CNS in core memory and context switches among different LNSes is also supported. To avoid one process use up all memory resources, the short-term paging decisions are yielded to kernel making sure that CPS of each process remains in its limit. Like scheduling, KMPS uses a page guarantee policy for all PMs. KMPS also supports replacement policy for replacing pages based on current CPS/LNS and a cost based priority function.

c) Protection: A new notion of capabilities with access rights is embedded into every object - procedure, process and execution environment. A clear distinction between policy and mechanism is evident here, as access rights are implemented by the construction of a type based subsystem. PM not having direct control over its processes is supported by KMPS, by providing suitable negotiation interfaces to PM through policy objects.

4. Evaluation
Although the paper has provided details on thier experience of integrating the design with implementation methodology on three mechanisms, no such evaluations on how did it affect performance or memory requirements on C.mmp processor is given. Detailed evaluations on paging mechanisms, memory being a costly resource at that point would have been helpful.

5. Confusion
Paper mentions that the short-term scheduling policy is made available to PM (using Kernel’s mechanisms), but in paging part these policies are yielded back to kernel contradicting the separation philosophy. Why so and more details are needed here? What is the way that each process is assigned to a PM? How does shared memory synchronization happen in case of pages being confined to CPS of certain processes? Also, how is page fault handled as relocation hardware does not support recovery?

Summary:

This paper explains how the designers of Hydra were able to build a flexible system which allows user defined processes a level of decision making and control over the underlying hardware while attempting to ensure system fairness and providing protection. They achieve this by separating policies (used by user-level software) and mechanisms (a means by which a kernel can implement these policies). This paper explains this principle with the examples of scheduling, paging and protection.

Problem:

The authors set out to design a system which gave control of the underlying hardware resources to user defined software but faced two challenges:

• They couldn't really trust user software to do the right thing
• Switching to user defined software whenever a policy decision is needed wasn't feasible due to the cost of context switching.

Contributions:

The most enduring contribution of this paper is the separation of policies and mechanisms. This separation allowed the authors to create a flexible system which still allowed the kernel to retain some control over the system. This control was used to provide fairness and protection to all the user-level software. While the authors admit that the set if mechanisms that they selected might not be ideal, the policy/mechanism separation concept is still sound.

Parametrized policies are interesting in the sense that it allowed KM processes to hand over control to the KMPS, reducing the number of context switches needed.

The protection structure which prevented a PM from gaining control over the address space of any processes under its control and allowing users to create their own policies regarding security seems a lot more robust than any of the other papers that we've read so far. The concept of a process with an address space and capabilities looks like a precursor to modern processes. In particular, the concept of having control switch to successive "top" processes seems similar to stacked subroutines.

Most of the compromises made in Hydra seem to be due to hardware limitations of the time. It would have been interesting to see what they would have done with better hardware.

Evaluation:

The authors do not evaluate the Hydra policy/mechanism separation system as part of this paper. The purpose of this paper is to explain this system using a few examples to describe how the compromise of not having absolute user-level control of resources could still lead to a flexible system.

Confusion:

I like the paragraph in which the authors explain how a system could be seen as a possible hierarchy of policies and mechanisms. This paragraph explains how policy and mechanism are relative terms. Who or what draws the line between mechanism and policy?

Summary: This paper introduced the mechanism/policy separation in the HYDRA system, in in effort to maximize the flexibility to any kind of heterogeneous applications running on the system while not complicating the design of the system too much.

Problem: HYDRA is designed to run many different applications and each of them may have their unique needs for paging, scheduling, or protection. If we confine the system to only providing one right decision for most programs, the needs of other programs will not be met. Furthermore, the system must provide some kind of fairness to applications, in addition to the flexibility to customize individual needs.

Contribution:
1. The idea of separating policies and mechanism in an operating system. This provides great flexibility to user programs.

2. Scheduling of every program is handled by a mode process called PM which interacts with KMPS. Therefore every process can determine how it will be scheduled. This is similar to Nucleons.

3. User program runs in protection mode. This means, a program cannot access the address space of another program. This will improve the reliability of the system a lot more because without doing that a buggy process can corrupt the address space of other processes and even crash the operating system.

4. Every process can have control over how paging works for itself. However drawbacks are (1) the mechanisms are complicated and sometimes a program does not have to know how paging works in order to run itself (2) memory can be wasted due to predetermined page numbers.

Evaluation:
The authors did not explicitly evaluate their system.

Confusions:
How does paging actually work? What do LNC, CPS, RPS refer to?

Summary:

The goal of this paper is to describe a flexible system where policy and mechanism are separated which provides protection and fairness at the same time. The authors present a set of arguments as to what is a part of the kernel, and how user process can work together along with a set of policies to interact with the kernel, giving the required flexibility to the user, but providing the necessary protection as well.

Problem:

The primary problem being addressed here is of making decisions about what should be a part of the kernel. How can user-level process get more control of making decisions but at the same time prevent malicious code to do something undesired as well? The authors present their design policy of separating policy from mechanism to achieve this goal.

Contributions:

To achieve the primary goal of policy mechanism separation, the authors describe policy modules (PM), KMPS and how this would help in scheduling and paging efficiently. Each of these contributions is discussed briefly below:

1.Policy modules, KMPS and scheduling:
A policy module, acts as a liaison to the KMPS to describe the user defined policies to the KMPS. Hence, different processes can define different scheduling policies and all can run at the same time, with the KMPS allowing switching between PMs. This gives the required flexibility to the system. Fairness is guaranteed as the KMPS would equally divide the time available to the set of PMs, which can then schedule processes according to their policy. The KMPS acts to implement the mechanisms and provides a set of operations to do so. Parameterized policy removed context switching overhead.

2. Paging: For paging, a replacement policy based on the priority of a page is defined. The priority is calculated using the set of references to the page in CPS, and a cost function, the details of the cost function still being obscure. Page replacement depends on the kernel, hence the goal of protection is achieved. Fairness is also guaranteed by providing a certain number of pages to the PM.

Evaluation:

The paper does not provide any evaluation or metrics. But the main goal of the paper was to describe how policy and mechanism separation is achieved and to that extent, arguments for every design decision is provided.

Confusions:

How is it decided as to which policy modules (PM) get which processes to manage? Instead of a multi-level schedule between KMPS and the policy modules using different scheduling policies, would it better to use a global scheduler ? How to ensure that 'malicious' policy modules do not affect the overall system performance ?

Policy/Mechanism Separation in Hydra
Summary:

This paper deals with the separation of mechanism and policy in Hydra which is taken as a design principle. This paper talks about how external policies can be created to manipulate the mechanisms of scheduling, paging and protection provided at the kernel level.

The goal of the Hydra system was to provide facilities to construct policies at user-level for the usage of the resources. The problem was when such policy decisions are moved to higher levels, we cannot trust the programs and also cannot allow them to perform privileged operations to make policy decisions. The paper talks about the separation of the policy from the mechanism to handle this problem.

Paging:
The use of CPS and RPS helps to efficiently use the memory. The process paging is taken care by the kernel and PM influences the short term policy by specifying the parameters. This again helps to avoid the costly context switch. By providing a guarantee of a specified number of pages for each PM, fairness is obtained. By making the kernel responsible for page replacement protection is ensured as there is no dependency on PM.

Protection:
In the Hydra, each object is associated with a capability which supports access protection. The kernel, by guaranteeing the result when a process negotiates with a PM, helps the processes to tackle precarious states.

Evaluation:

The design proposed by the paper is neither evaluated against any machine nor is claimed to have come out after a rigorous testing. Though it is claimed that the Hydra system is more flexible and better than a system with rigid hierarchy in many cases there are no performance measures that would nail it as a fact.

The paper says that a PM could logically be several processes waiting on a single mail box, cooperating to effect a single policy. When a message arrives, again there is a need to schedule these processes to effect the policy. How does this scheduling take place?

Summary

This paper tries to describe the separation of policy from mechanism aspect of the hydra kernel. The kernel is almost consistent of mechanisms while the user programs use these mechanisms to decide on important policy decisions on scheduling, paging and protection. The kernel, however, reserves a few basic resource arbitration policies which are used to guarantee fairness.

Problem

The problem the authors are trying to address in this paper is that they have learnt from ‘bitter experiences’ that existing operating systems which claim to do most in the average situations fail to satisfy in the few important cases because they are not tunable. This is because the policy is deeply ingrained in the operating system and there is no way user level programs can modify those according to their benefits while still adhering to tenets of controlled isolation from each other, security and memory protection. in this paper they strive to describe a system in which user level programs can tune the system through interfaces provided by the kernel.

Contributions

1. The kernel mechanisms do not allow direct access of hardware registers to the user level programs. These happen through well defined interfaces

2. There is a concept of parametrized policy. Context switching is very costly in Cmmp. So the object managing a process may set certain parameters in the process table. The kernel may use them to contact schedule process without concerning the object which decides the policy

3. The Kernel Multiprocessing System (KMPS) is the one that helps in scheduling user level processes. This is a parametrized schedulers. The policy module sets parameters in the process by interfaces like SETOCB and GETPCB which intern is used by KMPS for scheduling decisions.

4. Paging is handled by user level programs by using primitives like CPSLOAD and RRLOAD. Each PM is given a fixes set of pages to use for the processes it handles. This is called paging guarantee There are appropriate rape replacement policies too. Page replacement is detached from the policy module and is handled by the KMPS.

5. When more than one process try to run inside the same critical section of code, the negotiation mechanism is a nice way to deal with it

Evaluation

The paper has been a description of the hydra operating systems policy/mechanism separation. Many of the things have not been simulated and a few ideas are half-baked. No statistical information has been provided

Confusion

What are LNS, CPS and RPS? Are the pages in LNS not always equal to that of CPS? If not, why?

1. Summary

Hydra is a operating system focused on flexibility, This paper demonstrates the ways in which policy/mechanism separation allows hydra to cleanly achieve this flexibility. In particular, this was achieved in the domains of scheduling and memory management via the use of parmaterized policies.

2. Problem

The goal was mainly to build a flexible system, capable of supporting various models of resource management, while maintaining efficient use of the available system resources. And to this end, to separate policy from mechanism to make for a clean interface.

3. Contributions

To achieve more flexibility one might allow the PM to make every scheduling decision. But since the PM is itself a process, this sort of scheme would require an extra context switch on every scheduling decision. Instead, they use a parameterized policy. In this context this means that the kernel takes care of short term scheduling based on some parameters set by the PM, but in the longer run, the PM decided which processes are available to run. Thus the kernel works to ensure short term fairness and efficiency. All the above only references one PM, but hydra allows for multiple PMs and the mechanism for allowing for multiple PMs is simply that each PM states how much of the processor's time it requests. And hydra attempt to ensure that the processes from that PM get that amount of the CPU. In this way, the kernel takes on the responsibility for ensuring global fairness.

The other major component where they consider the question of policy/mechanism separation is in paging. Unfortunately, due to the details of processor design, it was not always possible to safely recover from a page fault. So they had to ensure that the entire accessible memory of a running process was mapped if the process was to execute. As such, page mapping decisions are not completely orthogonal to scheduling decisions. Although that in and of itself is perhaps not a surprise, but in this case this required that the mechanisms for dealing with page mapping are not completely orthogonal to the mechanisms for process scheduling. Whereas, on a modern system, one might expect that the mechanisms would be orthogonal, even if most of the reasonable policies would involve relating the two. Furthermore, with sharing of physical pages, especially between process of different PMs, it would be hard for a PM to keep track of which pages were in use by their processes. So instead, the kernel is responsible for ensuring that all of the requisite pages are in memory, and the PMs simply request that they be guaranteed a certain amount of memory for their subprocesses. But to prevent inefficient resource usage, in particular, to prevent the case of some PM having a lot of guaranteed but unused memory, these limits are soft, in that a PM may exceed their allocation if there are free frames. Finally, as with the case where a process that blocks would be stopped and handed back to the PM, a process which has had a page forced out by memory pressure would be handed back to the PM, allowing the PM to determine what to do.

4. Evaluation

While there is not much in the way of concrete evaluation, they do provide examples of the ways in which the implemented features might be useful, and how the mechanisms interact with policies in realistic situations. For example they explain how semaphores are dealt with in the context of the KMPS. And considering that the question at hand is not easily measured, namely the flexibility of the system, this is perhaps a reasonable effort and evaluating the situation.

On the front of resource allocation efficiency though, they really could have given more concrete numbers. While they do explain how their system should allow for efficient use of resources, it would have been more meaningful to see actual numbers attached to this. Especially since this is one of the few things within this paper that could have been concretely measured

5. Confusion

If the PM is itself a process, how is the scheduling of the PM itself dealt with, is it simply managed by the kernel? If it's managed by the PM, what happens if the PM were to block on something?

Summary
This paper presents the idea and need of policy/mechanism separation for Hydra (an OS built for multi mini processor at CMU). A reason why such a separation is required has been explained in three main categories - scheduling, paging and protection with examples.
Problem
The authors point out that older OSes with policies ingrained in kernel, do not perform best in all situations. The goal in Hydra was to provide flexibility and user-level control over system resources by designing a kernel that provides basics mechanisms. The user could then be flexible in designing policies based off the available mechanisms. The other challenge was to determine the appropriate restrictions to be imposed by the kernel and a way to absorb in it few policies in order to limit the user-space.

Contribution
1. This paper introduced the concept of separating policies and mechanisms to provide user-flexibility in system design. However, the authors have also emphasized that total separation can put the system resources at risk. User-space policies cannot be trusted completely. Kernel thus has to enforce certain (parameterized) policies too.

2. KMPS (Kernel Multiprocessing system) implements mechanism for scheduling of processes once the Policy module (PM) sets the parameters for the process object. The scheduler communicates with PM through a policy object. Parametrized policies are implemented by kernel to enforce fairness.

3. The HYDRA system was equipped with a hierarchical paging mechanism. Issues faced during paging policy viz – process paging, paging guarantee and page replacement. The relevance of pages in LNS, CNS and RPS in the system were exploited to deal with each of the problems listed above.

4. Protection mechanism have a clear distinction between the policy and the mechanisms. Kernel has mechanisms to detect incorrect access to system resources and thus also serves as a kind of a barrier.

Evaluation
The paper is on policy/mechanism separation in Hydra. No evaluation of any sort is relevant/required in this context.

Confusion
Why is the paging mechanism doesigned through several types of pages? What was the bottleneck?

1. summary

This paper describes the design of the HYDRA operating system which was one of the first systems developed for use in a
multiprocessor environment. The authors advocate the principle of a micro kernel where user level processes are entrusted with policies to build upon the bare minimum facilities provided by the kernel. Most of the paper is spent in explaining how the above mentioned design is incorporated in the context of three different operations - scheduling, paging and protection.

2. Problem

The authors contend that policies defined in previous operating systems do not work well for specific programs. Thus the efficiency of the program is affected.

They claim this situation can be amended by giving user-level processes control of the policies. The process can then fine tune the policies according to their own needs. Hence, the problem or issue is how to design an operating system which would entrust user-level processes with resource allocation while maintaining security, efficiency and fairness.

3. Contributions

The major contribution of the paper is the introduction of the idea of separation of policy and mechanism. As I understand it, the mechanism is the way to achieve an operation while a policy is the control/access over the operation. The paper then explains the details of how this paradigm is implemented.

The paper firstly explains the separation paradigm as applied to scheduling. There is a user-level scheduler (called a PM) defined. Note that the PM may be a set of processes cooperating together and there may be multiple PMs in the system. Furthermore, there is also a software called the KMPS. To this effect, the KMPS is mainly tasked with implementing the mechanism of scheduling processes while the PMs are tasked with setting the parameters to influence the policies for processes. Hence the separation is achieved. However, the KMPS can be viewed as a policy in itself as firstly it makes decisions regarding the competing needs of PMs and also makes scheduling decisions (since a switch to PMs for scheduling is inefficient). The scheduling decisions of the KMPS are however influenced by the parameters set by the PMs. Hence, there is a coupling of mechanism and policy.

The paper then explains the separation paradigm as applied to paging. Like with scheduling, it is inefficient to switch to the PM for paging decisions (i.e choosing the pages to be core-resident). Thus, kernel is again allowed to handle process paging automatically in situations such as when a processes is started, stopped and its top CPS changes. Note however, that the PM still has indirect influence over the paging as the paging policies depend on the PMs actions in starting or stopping process. However, the authors note that this level of control is not sufficient and so the PM is allowed (and encouraged) to control the max CPS size for each process.

There is however complete separation of policy and mechanism achieved in the case of protection through the use of capabilities.

4. Evaluation

The paper does not mention any performance metrics from the implementation of the system and instead only discusses the concepts. Hence, there is no evaluation to be found.

5. Confusion

For a paper which mentions the words (parameterized) "policy" and "mechanism" a zillion times, there is actually no clear definition of the terms in the paper (actually mechanisms are loosely defined as kernel operations). Hence, I sort of get what they are but not fully. It would be good if a precise definition can be given at the start of the class discussion.

I'm not sure what is meant by "the identification of a piece of software as a policy or mechanism is a relative one" (pg 133). It seems that there is a certain hierarchy in mechanisms/policies and certain mechanisms can be viewed as policies by higher level software? An example might help in explaining this.

I'm also not sure of how the complete separation of policy and mechanism is achieved in the case of protection and the part about negotiation is not clear.

Summary:

The paper describes a design of a microkernel that strives to provide a separation between policy and mechanisms. The policies can be developed in the user-programs and they can be implemented using mechanisms provided by the kernel. Three examples are given, viz. scheduling, paging and protection.

Problem / Goals:

The operating systems present at that time were all designed with a specific goal in mind and hence they were inflexible because the policies were hardcoded in the kernel. Hydra introduces flexibility in the execution environment by decoupling policy from mechanism and then allowing the user-level processes to define the policy.

Contributions:

The idea of the separation of policy and mechanism has been demonstrated through the examples:

1) Multiple policies can be defined at the user-level. There is a PM for each policy and multiple processes can associate themselves to a PM. PM is also a user-level process and it can set parameters for scheduling in a kernel module called KMPS. KMPS does the actual scheduling based on the parameters. As KMPS is an arbitrator, there is no need to switch domains for scheduling decision.

2) In Paging, the kernel provides the mechanisms to manage the pages within the three-levels of memory system (LNS, CPS and RPS). But the user processes can define their own policy of managing by using kernel mechanisms.

3) A full fledged separation is obtained in the Protection example. Kernel provides mechanisms that allow negotiation to take place between a process and its PM and that guarantee the results of the negotiation.

Confusions:

Who creates the PM? Modern OS's seem to have the scheduling policy embedded inside the kernel, why don't they allow users to define the policy?

1. Summary
The authors make the case for policy-mechanism separation abstraction, where the OS gives control of policy specification to user programs (in unprivileged mode), and the kernel implements mechanisms to realize these polices. The authors then present the design of three policy-mechanism separations (scheduling, paging, and protection) as examples of such an abstraction.

2. Problem
To design an OS that provides user programs control of specifying policy of resource utilization while ensuring fairness among multiple possibly competing policies that manage the same resources.

3. Contributions
The primary contribution of the paper is arriving at the policy-mechanism separation abstraction, and identifying the trade-off between amount of control to provide the user programs and minimization of performance overhead due to domain switching in realizing this control. The authors also design examples of policy-mechanism separations for process scheduling and paging using a two-level hierarchy involving policy modules and processes, where each policy module controls the policy for the processes under it. In the design, the authors choose a sweet-spot in the trade-off, where the policy modules specify the policy for the short-term (e.g., active processes and priority for scheduling) while the kernel handles the actual scheduling and paging for that time period avoiding the switch overhead for every scheduling or paging decision. The authors propose a novel capabilities abstraction that captures the access permissions of various objects to achieve protection policy-mechanism separation.

4. Evaluation
The authors performed no evaluation of the separation designs. The primary aspects of the system to evaluate would be whether fairness among competing policies was guaranteed and whether performance overheads incurred in policy specification were minimal.

5. Confusion
In choosing to provide only short-term control, the authors have designed a complex system for process scheduling and paging. Are such designs currently used by any real-world OSes? It is unclear whether the working set model of paging (achieved by setting max CPS size) would work in modern OS workloads.

Summary
The degree of flexibility of a system is determined by the extent to which the user defined policies have control over the resources/facilities. The separation of policy and mechanism contributes to the flexibility of the system. This separation is one of the basic design principle of hydra and was implemented by trying to push the mechanisms to kernel and the policies to user level. The paper explains the implementation of this design principle in context of process scheduling, paging operations and protection.
Problem
Providing user-level control over the policies(to make the system flexible) which determine the resource utilization may lead to 1)misuse of direct access to hardware and data 2)monopolizing the resource. The paper tries to address these problems by introducing the principle of policy/mechanism separation.
Contribution
The flexibility of scheduling the user-process was given to user-level scheduler 'Policy Module'. KMPS, portion of the kernel that implements a mechanism to support these policies, defines operations like START,STOP, SETPCB on process objects by the PM, based on which the KMPS makes its short-term scheduling decisions and thus providing the flexibility to PM to schedule. The paging system defines the means by which user may specify and alter the set of page objects which are present in primary memory and which may be directly accessed. Paging policy decisions are implicit by the PM's actions in starting or stopping processes.By choosing which process to run at any instant, it is also choosing the pages to be core-resident. Another major contribution of this paper is three-level-memory system of LNS,CPS and RPS. The paper also propose concept of a system Administrator. Only the administrator is allowed to modify policy objects. This provides an improved protection scheme
Evaluation
This paper mainly explains the design concepts and since no other systems have implemented these concepts, its not possible to compare. However, requiring the user to manually manage programs above a certain size (which is determined by hardware capabilities) is clearly not a good thing.
Confusion
The authors propose the idea of having multiple schedulers or PMs to run concurrently. All these PMs communicate with KMPS to implement their scheduling policy. Doesn't this result in performance degradation due to a lot of communication between PMs and KMPS ?

Summary:
This paper describes design of Hydra system which can provide user more flexibility in using the resources. Flexibility is achieved by implementing mechanism in the kernel and giving power to user in implementing policies in order to use it. Author discusses mechanisms and policies for process scheduling, paging and protection in detail.

Problem:
Operating system present at that time were less flexible and failed to work in special cases because policies and mechanisms both were implemented in kernel. Hydra provides more flexibility to users by allowing them to use resources they wish by providing minimal control over policies defined by users in order to guarantee fairness and avoid conflicting situations.

Contributions:
1. Separation of mechanisms from policies in order to provide more flexibility to end users.
2. Author introduces idea of Kernel Multiprocessing Systems(KMPS) which provides support for user level scheduling. Policy Module(PM) which is user level scheduler can implement its own scheduling policy for group of processes and scheduling policy among different PM's can be different. It can set priority, processor mask bits and time quantum for each process.
3. Parametrization was used in order to avoid context switch problem.
4. Mechanism in kernel to manage paging is discussed. It helps users to specify its working set and also helps kernel to decide which pages should be evicted thereby increasing efficiency of whole system.
5. New hierarchy of memory: LNS, CPS, RPS was introduced. CPS limit number of pages each process can uses. It can access more pages only by requesting PM.
6. Page guarantee scheme was introduced, efficiency of system was increased by allowing one PM to use free pages of other PM's.
7. Protection mechanisms are defined by treating everything as object and introducing capabilities in objects. Capabilities defines reference to other objects along with operations it can perform. Capability part of object can be modified only by kernel.

Evaluations:
Paper doesn't provide any evaluation or performance of new system. Also, most of mechanisms were not implemented completely.

Confusions:
Discussion about CPS and RPS will help.

Summary:
This paper discusses the design principle employed in Hydra system, which is that of separating policy from mechanism. In Hydra, the kernel provides the mechanisms, which are intended to support the abstracted notion of a resource, while the policies that tap into these mechanisms are left to the freedom of user programs.The paper drives home its core design philosophy of policy/mechanism separation by discussing in great detail three important examples: Scheduling, Paging and Protection.

Problem:
The operating systems in Hydra’s era implemented policies in kernel. These policies catered to the average case but failed to cater to the special cases, deemed important by users, thereby rendering the systems inflexible. The designers of Hydra tackled this problem of inflexibility by allowing the policies to be defined in user-level programs to make them amenable for adaptation and tuning.

Contributions:
The major contribution of the paper is its philosophy of separating policies from mechanism, which is at the heart of Hydra system. This philosophy is deeply embedded in three of its system components, namely scheduling, paging and protection. Hydra implements a parameterized scheduler, where KMPS provides mechanisms required to support policies implemented in user-level schedulers called Policy Modules (PMs). KMPS provides mechanisms in the form of START, STOP, PCB etc, which can be used by PM’s to schedule the processes under its purview through KMPS. KMPS only enforces the blocking and unblocking mechanisms, leaving the scheduling decisions entirely to PM’s. But, KMPS is not completely devoid of policies, but these policies are intended only to assure fairness among user level policies (through its guarantee algorithm), without breaking down the whole policy/mechanism distinction. Similar to scheduling, paging is implemented as a parameterized system, defined mainly by LNS, CPS and RPS of each process. The kernel provides mechanisms in the form of CPSLOAD and RRLOAD to manage various page sets of a process. Since PM’s are not always aware of which pages of its processes are in core memory due to the dynamic nature of sharing of pages between processes, paging and page replacements are handled in kernel. Again, some policies are defined in the kernel to aid the effective utilization of memory, the most notable being the priority based page replacement policy. Though scheduling and paging provides policy/mechanism distinction for the most part, certain fairness and efficiency related issues have forced some policies to be defined in kernel and the authors do a great job at justifying these necessary aberrations. But unlike scheduling and paging, protection structure in Hydra provides a clear distinction between policies and mechanisms.

Evaluation:
This paper does not provide any evaluation of the Hydra system. But in all fairness, the main objective of the authors was not to evaluate the system, but to expound the philosophy of policy/mechanism separation.

Confusions:
Is the relocation hardware mentioned in the paper something akin to a hardware based page table walk?
How are processes assigned to a particular PM?

1. summary
This paper presents the design and implementation of the Hydra system focusing on philosophy of separating "policy" and "mechanism". Separating policy from mechanism, (leaving policies to the user level process and kernel handling mechanisms) hydra presents itself as a flexible kernel. In this paper they discuss the trade off and design decision made in three mechanism, scheduling, paging and protection.
2. Problem
Hydra tries to address the issue of policy binded kernels which makes OS less flexible. While generic polices might work for few cases but there are cases in which more process specific polices will be better.
3. Contributions
The main contribution of this paper is the idea of separation of policy from mechanism. This paper realizes this notion in three mechanisms scheduling, paging and protection.
1. Scheduling decisions are left to the PM's(a another user process). Multiple processes can associate with a PM. But since PM is a another user level process a context switch would be costly just to know the scheduling decision. So the actual scheduling is done by KMPS. PM places certain parameters in the PCB of the process which is used by the KMPS to schedule them.
2. Kernel mostly handles the paging because of hardware limitation and for efficiency. Since scheduling and paging are very closely related, it is better to to handle paging and page replacement accordingly to the scheduling decisions.
3. Protection is offered by the "capability" abstraction. If a process needs to communicate with the PM(scheduling during the execution of critical section ), negotiation mechanism are also present.
4. Evaluation
Like previous papers in the course, this paper too didnt have any evaluations. As a matter of fact there were few mechanism which was not implemented and few design decisions yet to be decided at the time of writing this paper.
5. Confusion
More are said to be handled by PM, but who maintains PM ? who assign process to particular PM ? What is the modern OS equivalent of PM ?

Summary:
The paper discusses various design decisions made to separate policy and mechanism in Hydra, the first microkernel. An elaborate discussion is carried out about its effect on scheduling, paging and protection mechanisms implemented in the kernel.

Problem/Goals:
Putting mechanisms and policies together in the system kernel makes it inflexible, harder to tune and complex. Hydra aims to have user-level control of policies for utilization of resources providing more flexibility and allow multiple policies geverning the same resource to exist, when appropriate.

Contributions:
1. Separation of Policies and Mechanism (High level policies such as schedulung and protection, Low-level mechanisms such as message dispatching).
2. User-level scheduler called policy module to define various parameters to schedule processes in the kernel.
3. Parameterized policy as KMPS mechanism for making scheduling decisions. It also removes the overhead of switching between the domains (or context switch).
4. Fairness among multiple policy modules through guarantee algorithm.
5. Paging mechanism and policies are affected by hardware architecture. Policy modules could affect it by changing CPS size etc.
6. Protection policies on the top capabilities providing a clear separation between protection policies and mechanisms.

Evaluation:
The paper focuses on the design aspect of microkernel w.r.t. process scheduling, paging and protection and does not provide any stats to support the decisions made.

Confusion:
The author talks about "special cases" where extant operating systems fail in the Introduction. What are those special cases?
Could not fully understand the paging mechanism and policies.

Summary:
The paper discusses the policy/mechanism separation model in Hydra, and the flexibility it allows at user level for resource control policies.

Problem:
To construct operating system facilities as normal user programs, in order to provide more flexibility in an operating system.

Solution:
Policies are provided in user-level software to control resources, while mechanisms are in kernel to support the implementation of these policies. But this distinction is not strictly binding. One exception to this implementation is the kernel mechanism which are parametrized policy. This is done in order to avoid overhead due to rapid decision situations.
Three main examples of policy/mechanism separation in Hydra are KMPS, paging, and protection. In KMPS and paging parametrized policy is preferred. Though the control over scheduling is more direct, comparatively. Only protection is clearly based on separation model.

Evaluation:
No evaluation to show the benefits of this separation.

Learning/Confusions:
-Is the policy and mechanism separation similar to what happens during system call, when control passes from user to kernel mode in current OSes?
-The parametrized policy in the paper is more like a work-around to the policy/mechanism separation proposed in hydra. Maybe, better design could be parametrized model in itself? Though the idea is to give the user-process more control of resources, in paging it is said that the kernel handles the process paging essentially automatically. Similar handling by the kernel goes for scheduling as well. The purpose of the separation seems defeated this way.

Summary: This paper introduces the principle of policy/mechanism separation in system HYDRA. Thie separation aims to giving user-level processes more flexibility. The paper introduce the separation on three mechanisms: schedulgin, paging, protection and how the policies can be constructed based on these mechanisms.

Problem: In operating systems, the flexibility of user-level softwares depends heavily on whether it can utilize the assigned resources (by policy). This flexibility has the restriction, such as they cannot directly access hardware or other processes' resources. Therefore, people need to be carefully about which policies is allowed by user-level softwares.

Contribution:
1. In scheduling, the paper proposes KMPS (The kernel multiprocessing system) which allows a user-level scheduler. The mechanism is a parameterized policies which allows scheduler to run as a user-level process and concurrency. The reason of parameterized policies is to make decision quick.

2. The paging mechanism provides the fundamental functionalities to make the user-level processes managine the assigned pages: page frame allocation, memory competition among processes, and page replacement. CPS (current page sets) and RPS (relocation page set) is used, CPSLOAD and RRLOAD are used.

3. The protection policy/mechanism separation so that it supports selective access to information. So the process can choose mechanism to negotiate with the PM about the information to access. For problem of the execution of critical sections, there are processor mask, CPS limits and additional operation RUNTIME to do the negotiation.

Evaluation: The paper does not give quantitative evaluation of the performance of the polycy/mechanism separation. This is mainly due to the theme of the paper is design philosophy behind specific systems.

Confusion: Actually, I do not see a clear separate between policy/mechanism in scheduling. How to generalize their separation philosophy, there is no clear, well-defined principles.

1. Summary
This paper describes how the Hydra project has attempted to separate the implementations of policy and mechanism by building a kernel almost entirely of mechanisms. It focuses on three main areas scheduling, paging, and protection.
2. Problem
Existing operating systems at the time this paper was written were limited in flexibility by the lack of separation between their policies and the methods to implement them. The goal of the Hydra microkernel was to leave the definition of complex policies to higher level systems and their designers.
3. Contributions
Hydra includes the Kernel MultiProcessing System (KPMS), the section of the kernel that supports scheduling of user processes. More than one scheduler can run at once, and a failure in one is not meant to harm the others.

The KPMS handles the actual stopping and starting of processes, while passing messages about its state to individual user level Policy Module (PM). The PM is allowed to make decisions regarding the scheduling rule the KPMS should implement. Each PM is only allowed to schedule a certain share of resources, which is more or less a policy that got mixed into the kernel. PM's are guaranteed a minimum share of the CPU which is distributed among the other PMs if it is not used.

Memory paging is also managed by the PM, but there seems to have been a large amount of policy that was not practical to remove from the kernel here as well. The PM is able to set the size of the current page set for a process, and each PM is guaranteed a number of page frames. The problem (and solution) with this is that the guarantee also acts as a defacto limit for each PM unless they "borrow" unused pages from other PMs and risk having them reclaimed.

Access protection is provided that stops a PM from accessing the memory of a process, but exposes the PM to the process which allows a process to decide whether to provide service.

4. Evaluation
The fairness algorithm for using multiple PMs is not evaluated or even discussed because it was not implemented and existed only in theory. According to the paper, some simulations were run but those results are not shared.

Similarly, no quantitative evaluation of the paging policy options discussed is presented. The ideas presented for handling processes of PMs that have gone over guarantee are hard to evaluate without any testing having been documented.
5. Confusion
How are policies regarding the PMs themselves determined? They seemed to be the one point where policy/mechanism were mixed in the system, but how are things like the pre-determined guaranteed minimums negotiated?

1. Summary
In the paper, the authors propose the Hydra system which is implemented as a kernel composed mostly of mechanisms and resource allocation policies is determined by the user level processes. The authors explain how the separation of mechanism and policy was achieved in Hydra in three cases: scheduling, paging and protection and argue why certain design decisions were taken eg. why the kernel must still have minimalistic policy implemented.

2. Problem
Hydra attempts to address the need for a flexible micro kernel that allows a user to create his or her own operating environment so that each user level program can tune the system to its own needs.

3. Contributions
- defines a parametrized policy as a kernel mechanism (as the kernel cannot possibly support all conceivable user defined policies, since some will violate fairness guarantees or protection requirements)
- proposes a KMPS(Kernel Multi Processing System) which aims to run the process scheduler as a user level process(Policy Module) and allow multiple schedulers to run concurrently
- addresses the fairness problem in scheduling the processes from different PMs by the notion of "rate guarantee"
- each process has a process context block which contains the scheduling parameters such as processor mask, priority, time quantum and CPS size
- allows a user program to explicitly define its current working set which helps the kernel to make better decisions during process paging
- prevents the PM from accessing the capabilities of a process, but exposes the PM's complete information to the processes, provides examples of how kernel acts as a negotiator with PM to handle change in processor mask, exceed of CPS limit and access to critical section

4. Evaluation
The authors mention that some mechanisms are yet to be implemented and have only been simulated. Since the paper emphasizes on the design philosophy, statistics comparing the system against other systems(in which mechanism and policy are not separated) are not provided.

5. Confusions
- Would not switching between multiple scheduling processes(one by KMPS among processes of different PM's and another at each PM level to determine which process to run among the pool of processes it is in charge for) incur more overhead rather than using a single global scheduler?
- How are PM's created initially? If it is by the kernel, how will it know the various needs of the user programs and create that many PM's? If the user process creates PM, each process can create its own PM which would effectively be like scheduling all the processes using a global scheduler?
- What is the need for PM identification (I understand why PM's must not be allowed to access the LNS and capabilities of the processes it interacts with, but why should the LNS know the complete information such as trustworthiness and reliability of the PM)?

Summary:
The authors have highlighted the implementation of policies and mechanisms in various modules of the HYDRA system. The design principle was to allow most of the resource allocation policies to reside in the user level software whereas the kernel composed of mechanisms for scheduling, paging and protection and few policy decisions which were entrusted with the work of resolving conflicting requests.

Problem:
The authors claim that other operating systems with policies implemented in them are unable to perform in special scenarios as modification to policies to satisfy the applications requirements was very difficult as these policies were the core component of the operating system. The authors also claim that other paging systems enabled policy modules to leak information about the processes.

Contribution:
1. HYDRA facilitated the implementation of user level control of policies for resource allocation. Kernel comprised of mechanism to implement these policies. The kernel mechanism could be enforced by user level software (parameterized policies). This enabled fine tuning of the system to the requirement of the application thus providing more user level flexibility.
2. The KMPS is designed to allow the process scheduler to run as a user process and multiple schedulers to run simultaneously while just enforcing blocking and unblocking.
3. The designers provided KMPS with a well defined set of functions for handling processes (start/stop) as well for the Policy Module(PM) to read or set the fields in the PCB. It also enables communication with the PM via the policy object.
4. This design contained components like time guarantees to each PM of execution of its processes and policies associated with these guarantees which preserved the fairness in the system.
5. One of the main contribution of this paper was the introduction of the three level memory system (LNS, CPS, RPS pages) and providing the user programs with the primitives to manage these pages. Fairness is also assured by the kernel by guaranteeing the PM with a fixed number of page frames.
6. The HYDRA system provides the flexibility to the user to develop its own policies on sharing data by allowing it to create protection structures
7. This system kernel guarantees that it will return error to the PM whenever it tries to execute a process which is blocked, trying to run on a processor which is not available or attempting to exceed its CPS limit.

Evaluation:
Although the paper doesn’t not mention about any performance comparison with other operating systems, it convinces the reader that this design provides the programmer of user level software to have control over manipulating the behavior of the OS to its requirement unless it is trying to violate any fairness policy of the kernel.
Also the HYDRA system is unable to provide a balanced policy to reclaim unused page frames granted to PM which needed it. Lack of demand paging due to hardware restrictions limits HYRDA’s flexibility.

Confusion:
How does the PM decide which processor is better for its processes as the paper mentions that all the processors have different features? How does the PM know what kind of operations does the process plans to do and decide on the processor?

Summary:

The author describes the separation of mechanism and policy in Hydra as a basic design principle and presents three such mechanisms: scheduling, paging and protection in detail.

Problem:

The idea behind the Hydra design was to enable construction of OS facilities as normal user program and allow policies to be defined by user-level in order to provide more flexibility and easy tuning. The solution design should also be practical as user level programs can be malicious and can monopolize resources and in addition rapid policy decision may result in costly domain switching.

Contribution:

The author introduces the idea of policy/mechanism separation which means that the policies are encoded in user-level programs and we have mechanisms in kernel to implement these policies. The paper explains the policy/mechanism separation with the help of below mentioned points:
1. Kernel mechanism as parameterized policy: long-term policies enforced by user level s/w can avoid domain switching cost.
2. KMPS as parameterized scheduler targets to allow process scheduler to run as user level process and allow multiple schedulers to run concurrently.
3. Three level Hierarchy in Paging : LNS (Accessible resources) CPS (In-core resources RPS(in-core & addressable). Kernel performs paging & page replacement whereas PM only determines which process to run & its max CPS
4. Access Protection enables clear distinction between policy/mechanism as Hydra provides capability-based system which supports selective access to information.
Kernel provides a number of mechanism that allow negotiation b/w process & its PM to guarantee correct result

Evaluation:

The paper provides no detail on the result of Hydra’s execution and neither provides any evaluation details of mechanisms implemented as mentioned in the summary.

Confusion:

In section 3.1 author says that for larger programs >32K the user is required to manage these sets. Isn't the user supposed to know the underlying memory? In this should it be kernel’s responsibility?

Summary:
The paper presents the policy and mechanisms of the Hydra operating system. The idea is to allow users processes more flexibility in how the operating system interacts with them and to make the OS simply a set of mechanisms.

Problem:
Hydra aims to add some flexibility to operating systems. Many operating systems of the time seem to have been designed around a specific set of assumptions, Hydra hopes to make as few assumptions as possible and leave most of the decisions up to other programmers.

Contributions:
The idea of policies and mechanisms seems to be the key contribution in this paper. The kernel is slimmed down to the bare minimum, pushing more work onto user processes. This allows some flexibility in some cases where perhaps a set of processes could be scheduled more efficiently by another user process that has some awareness of how they operate. Hydra extends the idea of policies/mechanisms across process scheduling, paging, and protection. In the cases of scheduling and paging, user-level processes called PMs make some decisions on how some set of regular processes are scheduled or how their pages are handled.

Evaluation:
The authors discuss heavily the value they perceive in allowing user designed PMs to control some aspects of the operating system but fail to note the burden this puts on programmers who simply want something softer than bare metal.

Confusion:
I was unsure of a scenario where a PM having some knowledge of its processes would be able to schedule them more efficiently than another PM.

1. Summary
The hydra project is an attempt to separate functionality between the kernel and userspace using policy/mechanism separation. The authors attempt to split scheduling, paging, and protection support in this manner, to hopefully provide fast mechanism support in the kernel, while providing customizable parameterizations in userspace.

2. Problem
Policies which are intertwined with mechanisms and “baked” into the kernel work well for the common case, but fail in many important special cases. The solution is to allow programs that define policies direct hardware/data access - this is obviously an issue. It is difficult to ensure fairness and provide basic speed/protection guarantees to programs. The paper attempts to address this issue.
3. Contributions
The main contribution of this paper is the principle of policy/mechanism separation. The principle says that policies (like scheduling type) should be provided in user-level programs that are separate from the kernel. These types of decisions have no need for hardware level access, and can operate through interfaces provided by the kernel. Mechanisms, on the other hand, are kernel level operations that can directly access hardware/resources and implement the policies specified in user-space. This clean separation is still strived for today in system design.
While the authors mention that the goal is to entirely separate mechanism/policy, I felt that the second main contribution were their failures in completely decoupling logic. For example, both scheduling and paging required some “policies” directly in the kernel, originally meant for only mechanisms. Scheduling required a simple kernel level policy in which each PM was guaranteed a share of CPU time. Paging required a similar kernel level page guarantee to each PM to allow fairness. The kernel also handles the page replacement policy in order to avoid costly context switches, improve security, and fully utilize memory. In each case, the authors show that the separation of policy/mechanism are not as simple as desired. I assume this paper sparked many discussions on proper separation.
4. Evaluation
There are no performance statistics included in the paper whatsoever. However, the author’s goal was to design a “conscious separation of mechanism and policy,” so performance metrics are not expected. Instead, they outline their system design and show that they have been moderately successful. The system has achieved some degree of policy/mechanism separation. In the cases where this separation was not possible, they clearly explain their design decisions. The summary states that the search for a successful, minimal set is ongoing.
5. Confusion
This seems to be the first multiprocessor system that we have seen - was this an achievement at all, or was such a system common in 1975?
How does a PM actually create a process in this scenario? (The paper outlines the SETPCB/START commands, but doesn’t give much more information as to the underlying mechanisms)

Summary :

The paper talks about the separation of policy and mechanism in Hydra mainly with respect to the concepts of scheduling, paging and protection. The authors highlight the design considerations and also reason out why certain policy decisions are to be made by the kernel.

Problem :

The problem in question is to design a microkernel by following the principle that the kernel implements the mechanisms and the user-level programs are give the flexibility to define the policies.

Contributions :

1. Flexibility is provided to user level programs called the policy modules to perform process scheduling. The Kernel Multiprocessor system is responsible for the implementation of the mechanisms for these policies.
2. Multiple policy modules can run simultaneously and can handle scheduling of processes assigned to them.
3. The policy module can set parameters like priority, processor mask, time quantum which would be used by the KMPS to allocate CPU time for the processes associated with that policy module.
4. The KMPS is said to guarantee fairness and rate guarantee in process scheduling amongst multiple policy modules by a scheduling guarantee algorithm.
5. The system is highly restricted by the hardware functionality and requires the user to manage the page sets that are required in core memory. The Current page set (CPS) contains the pages that are currently in memory and the relocation page set (RPS) contains those pages that are in memory and can be addressed using the relocation hardware. The paging mechanism uses the CPSLOAD and RRLOAD operations to load the CPS and RPS according to the initial CPS/RPS configuration.
6. The process paging policy, paging guarantees and page replacement strategies are done at the kernel level since to avoid underutilization of memory. Priority based mechanism with LRU is used as a page replacement algorithm.
7. Kernel provides a couple of mechanisms to handle undesired operations performed by the PM such as unblocking a process before semaphore is released, not restarting a process with a higher CPS limit as required and stopping a process when executing a critical section etc.

Evaluation : The paper highlights only the design considerations, they talk about the limitations of the hardware which had been used (with no demand paging) but there is no quantification of the performance benefits of such a design.

Confusion :
How are processes assigned to PM’s? Fairness across the various PM’s is handled by distributing CPU time across PM’s. If a PM is malicious/buggy, how is fairness within the processes allocated to PM guaranteed?
Doesn’t this involve a higher overhead of communication between the PM’s and the KMPS and thus affect the performance?

Summary

Giving user level processes more control over their system resources would allow an operating system to be far more useful. This paper proposes the Hydra system, which separates mechanism and policy to an extent that allows user processes to gain some control over their scheduling, paging and protection.

Problem

Operating system policies and mechanisms are designed to work well in common cases, but often perform poorly for special cases. Giving user level programs control over their resource policies can solve this problem, but also risks security and fairness. An operating system should be able to accommodate some balance between user-level control and a certain level of kernel policy.

Contributions

The major contribution in this paper is the concept of separating mechanism and policy, allowing user level programs to gain some control over their resource policies. This is accomplished by setting up several new abstractions in the kernel, notably a Kernel Multiprocessing System (KMPS) which supports policies for scheduling, a user-level scheduler called the Policy Module (PM), a three level memory system for paging containing the Local Name Space (LNS), CPS (Current Page Set) and RPS (Relocation Page Set).

The separation of scheduling duties between the kernel-level KMPS and multiple user-level PM objects allow for processes to claim some resources without starving the rest of the system. Paging is implemented by giving the kernel most paging duties, while also allocating some guaranteed number of page frames to the PM, which gives the user process control over replacement policies. Protection is generally handled automatically by the kernel, although there are some mechanisms in place that processes can access if they have specific needs.

Evaluation

The paper provides a detailed technical description of the Hydra system but does not provide any quantitative measures or formal evaluations. The conclusion does mention that the mechanisms implemented need improvement; the paper also hints at some problems with performance and correctness but does not go into any significant detail about them.

Confusions

I was generally confused by the abstractions presented, most notably about how the Policy Modules are implemented and operate. This was a challenging paper! It was especially difficult because I couldn't think of any modern day equivalents; do any of these concepts live on in Windows or Linux?

Summary
This paper describes three parts of the Hydra system focussing on the policies and mechanism and how Hydra separates them. The authors discuss the design of the scheduling, paging and protection of the Hydra multiprogramming system.

Problem
Putting policies and mechanisms inside the kernel makes the system architecture complex and inflexible. This paper aims to solve this by establishing a clear separation between policies and mechanism.

Contribution
The authors aim to separate policies and mechanism in a multiprogramming system. The mechanism is implemented by the kernel while the policies are left to user level programs. This makes the system flexible and extensible. The paper explains how the separation is built into the system using three examples of scheduling, paging and protection. Low level, short-term scheduling is handled by the kernel. It provides mechanism for user-level scheduler(policy module) to supply parameters to control overall scheduling policy of a subset of all the processes in the system. The kernel communicates to the policy module via messages. In the case of paging, each process must specify its working set or current page set(CPS) so that the pages are loaded into memory. The paging structure is divided into three levels LNS, CPS and RPS with each being the subset of the previous. This helps in designing scheduling policies. The only parameter that the PM can specify is the maximum number of pages in the CPS of a process. Page replacement is handled by the kernel as the PM never has all the information to make good replacement decisions. For providing access and control protection, the policies are completely at the user level while the mechanism is completely at the kernel level.

Evaluation
The system as described in the paper was not completely implemented by the authors and hence they do not present any evaluation of their system.

Confusion
Hydra is designed to be a non-heirarchical system. However the use of policy modules as an abstraction does seem like adding a level of heirarchy above the kernel. Also, the policy modules are defined by telling what they do. It is not mentioned how they are implemented or scheduled themselves.

1. Summary
The current paper discusses the concept of providing kernel level facilities like process scheduling, paging, protection to a user level program. In order to facilitate this in a protected and controlled fashion, the authors separate a kernel program as policy and mechanism between the user and kernel level. Often times, these layers overlap with each other.
2. Problem
Having a static kernel policy can limit the performance of a system as it addresses the common case scenario. On the other hand, providing access to system resources to a user level process can be detrimental to the security of the system. This paper addresses this issue by separating a kernel service into policy, which is adaptable and implemented by the user level program and mechanism, which is protected and implemented by the kernel. This gives rise to a new set of issues like conflict between user level programs, guaranteed fairness and service, delays in user level policies etc.
3. Contributions
Each process in the system is associated with a policy module (PM). The kernel level scheduler KMPS is configured for short term rapid scheduling decisions by the PM. The KMPS handles process of scheduling the process, managing its pages, suspending the process and managing the process control blocks. In addition, the KPMS provides policies to guarantee fairness and cpu time. The paging policy is provided as a kernel mechanism since it is closely connected to a process schedule. The user programs are provided with capabilities to load certain core pages or relocation pages into the working set. The kernel provide additional mechanisms to address the limitations of hardware resources and to reduce the contention between multiple PMs. The PMs provide protection policies, which the processes may choose not to use. The PMs provide some form of certification to display its trustworthiness. In addition, the kernel mechanisms also enable negotiation between the process and PM over a conflicting resource.
4. Evaluation
Since this was a design paper, the authors did not provide any evaluation.
5. Confusion
I did not quite understand the concept of LNS. How is it relevant to paging mechanism?

Summary:
The paper provides an overview of the principles and philosophy that drove the concept of policy/mechanism and introduces the concepts of minimalistic design that was adopted in the design of HYDRA. The paper also mentions some tradeoffs that the designers had to make to make the system efficient and provide security.

Problem/aim:
The design of hydra was mostly based on the intent of providing flexibility, in terms of policies, i.e. deciding what to run and for how long etc, to the users. In doing so, the designers had to ensure that the user processes did not misuse or monopolize the resources and also try to protect user data and system from malicious/buggy programs

Contributions:
The fundamental idea of separating policies from mechanisms was the biggest strength of the approach. The concept is still in use today and helps system developers visualize problems in a structured way. The idea of having a Policy Module (PM) and parameterized KMPS policy, to implement user-level policies is attractive, but I think it adds a level of indirection, and communication between the HYDAR kernel and PM, for process control handled with Policy object, might introduce significant overhead. Also, the KMPS leaves the job of rescheduling of blocked processes to the PM, which I believe is inefficient since the PM had scheduled it already based on requirements. An alternative to this could have been implementation of something like a process queue for blocked processes, from which the kernel could have directly executed after the condition for wait is satisfied. In the implementation of multiple PMs, the authors mention that the KMPS was responsible for scheduling among PMs, which seems to conflict the idea of user level policies. But the authors justify it by saying that this was done to ensure fairness to user processes. The idea of using CPS and RPS shows the attempt of the designer to work around the hardware constraints or limitations. The KMPS control for paging is another place where some of the policies were introduced in the kernel. This was done to make the system faster. The authors not only talk about regular paging policies but also pages shared between PMs and within PMs, which had unresolved issues. Page replacement in KMPS also includes some policies, which is done for efficiency reasons, i.e. page replacement requests are dynamic and waiting on PMs to decide on pages to replace can be very slow. The effects of hardware on design features such as CPS, inclusion of page replacement in the kernel etc have been mentioned which I feel are very reasonable considering the fact that the design of such kernels were highly machine specific. The key features in the protection system insulation of LNS and CPS from PMs, and some security for LNS access by PM, for checking the credibility of the PM.

Evaluation:
The authors provide no evaluation of the performance of the kernel. Some of the statistics that could have strengthened the paper are – maximum number of concurrently processes, number of concurrent user etc.

Confusions:
How were processes assigned to PMs? How was the presence of multiple processors exploited?

1. Summary
This paper introduces policy and mechanism separation which is important in creating a safe environment for processes in an operating system. This idea is illustrated in three aspects of the Hydra System of scheduling process with KMPS, Paging and protection.

2. Problem
In an operating system, policies suppose to work often fail to do so in special cases. Need to prevent programs corrupt each other as well as monopolize any resource. What’s more, decision need to be made rapidly. However, it is impractical to require a policy decision each time when a program runs, for both protected domains are needed and switching between programs is costing.

3. Contributions
The principle of policy/mechanism separation. Policies in user-level build a “safe” hardware operation and mechanisms in kernel that implement policies provide the means by which overall, long-term policies can be enforced by user-level program and avoid a big cost in switching mechanism for decisions.

- KMPS is used in process scheduling, processes are associated with PMs. KMPS defines process and operations on them. KMPS also defines policy and uses a priority scheduling algorithm. It is a parameterized policy with priority, processor mask, time quantum and maximum current pages size as parameters.

- On paging operations, the paging system defines means by which the user may specify and alter the set of page objects. Paging uses LNS, CPS and RPS to define a three-level memory system. It is more indirect than control over scheduling and strongly affected by the hardware architecture such as the length of address and the size of page frames. Hydra kernel deal with issues in processing paging, guarantees and replacement.

- On protection, Hydra provides a capability-based system that supports selective access. To provide control protection, PM identification uses a “system administrator” to alter data that contains information about the trustworthiness and reliability of a particular PM and the services it may provide. To deal with the problem of execution of critical sections, there are inner characteristics such as processor mask and CPS limits as well as additional operation called RUNTIME to negotiate between processes and PMs.

4. Evaluation
The separation of mechanism and policy is a very important concept in the designing of an operating system. Though it is a compromise as the author says, it achieves well in both isolated environment for processes and fast switch between them. More problems are brought as the separation complicates the system, luckily many inner features help deal with these problems.

5. Confusion
How to ensure that the “system administrator” is behaving appropriately?
What’s the paging procedure with LNS, CPS and RPS in detail?

Summary :
The paper presents the ideas of policy and mechanisms in the Hydra system and how the different resources are handled by the user-level and the kernel processes.

Problem :
Any operating system has to be built in a very flexible way such that the user should be given the chance to implement things like resource access or page replacement in the way he wants for his processes. But at the same time, there should be some level of kernel intervention because if user programs are allowed to access hardware or data, they could destroy other programs. They could also monopolize over any resource. Hydra comes up with a solution to this problem by introducing policies which can be defined by the users and mechanisms by which the kernel executes these policies.

Contributions :
1. Defining a clean separation between policies and mechanisms and why both are needed.
2. Designing of the “kernel multiprocessing system” which handles user defined policies and implements them ensuring fairness among multiple processes at the same time regarding resource allocation and paging.
3. Implementing the “policy module” through which user processes can define parameters according to which the processes will be executed.
4. Paging is completely handled by the kernel unless the user process wants to do changes like changing the size of the CPS and so on using some procedure calls that are clearly defined.
5. Adding protection layer in cases where the user processes do not trust the policy module.

Evaluations :
The paper is a very experience narration kind so the authors do not present any evaluations as such. Although, they state bad/inefficient experiences with their system and solutions to how they might be solved. For example, they state that instead of ranking pages as 0, 1 or 2 they can use many more slots and values for different purposes like prefetching or important pages.

What I found confusing :
How does RRLoad happen? Do pages always get fetched from core on request? Or are there some predetermined pages in the relocation hardware that will get swapped?

Summary:
The paper describes the separation between policies and mechanisms for three components in Hydra system, namely Scheduling, Paging and Protection. The design choices for implementing kernel primitives are reasoned out based on how much could they could distinguish between policies and mechanisms, the hardware restrictions, and the interrelation between Scheduling and Paging policies.

Problem:
The goal of the Hydra system was to provide flexibility in resource allocation policies to facilitate the construction of operating systems as user level processes. However, every time that a policy decision would be needed the system would have to undergo a costly context switch between execution domains. So the idea was to provide policy/mechanism separation which means the user level processes would define the policies and the kernel would be a minimalist set of mechanisms, needed to implement those policies.

Contributions:
1. The idea of implementing mechanisms as parameterized policies at the kernel overcame the context switch problem. This was especially important in KMPS as not only were scheduling decisions made faster, but there could be multiple concurrent policy modules each governing the schedule of their processes. Making good use of the Hydra’s notion of objects, the policy object allowed for multiple processes to collaborate as a policy module.

2. Treating pages as objects in the Hydra environment the authors were able to cleverly work with the hardware restrictions posed by the memory architecture of the C.mmp system by creating a memory hierarchy from the RPS, CPS and LNS objects. The CPS also enables the PM to limit the pages a process can use so as to prevent rogue processes from an unfair takeover. A flexible paging guarantee scheme is discussed with concepts of under and over guarantees for more effective utilization of the memory between PMs.

3. Decoupling the page replacement policy from the PM had the benefit of not only simplifying the PM’s responsibility but also it was better from a security perspective as the PM gets only what it needs to know so it won’t be another point of vulnerability for leaking sensitive information like the the process pages.

4. The negotiation mechanisms are a good way for the kernel to double check erroneous behaviour from untrustworthy PMs in handling critical sections and policy parameters like CPS limits and processor masks.

Evaluations:
As the paper was mostly about the reasoning behind particular design choices for separating policies and mechanisms there wasn’t much to go beyond the justifications provided for their choices. With empirical testing the issue of messaging overheads between PMs and the KMPS might emerge.

Confusions:
Could you please elaborate on how access protection was implemented by information hiding?

Summary
The authors of the paper attempted to create a system in which the policies of the system were separate from mechanisms that are used to achieve those policies. In reality, they only partially achieved this as they discovered through implementation that the kernel must implement certain policies in scheduling in order to ensure fairness in the system and certain policies in paging in order to improve performance. Protection was the only area of the system in which this abstraction was cleanly implemented.
Problem
The problem this paper was trying to solve was that when policies and mechanisms of the system are too intertwined, the system lacks flexibility. The authors of the paper recognized that the user should have the ability to set scheduling patterns and page replacement policies of processes, but they shouldn’t have access to the actual mechanisms to achieve these policies. Applications in this system needed to be able to tune it to their own needs, which could be drastically different than other applications. Thus, their solution was to separate the policies from the mechanisms in scheduling, paging, and protection between processes.
Contribution
The paper presented the implementation of their system in which they attempted to separate the policies from the mechanisms. In scheduling, they decided to defer the scheduling policy decisions to a user process called a PM. Each PM would have associated processes and could schedule the processes as it pleases. However, they found that it is inefficient every time a process needs to be scheduled to consult the PM to make this decision. Therefore, the actual scheduling of the processes was deferred to the kernel (called the KMPS). Each process contains a Process control block, which contains parameters set by the PM. When the KMPS schedules a process, it simply checks the control block instead of context switching to the PM. A similar abstraction is provided at the page level. The KMPS also handles certain aspects of paging, such as when a process wants to run, the KMPS will load the initial CPS (current page set) into memory. Protection is the area that is the most cleanly defined in terms of separation of policy and mechanisms. Hydra provides a capability abstraction which allows the ability of certain process to access certain objects. This forces a natural separation of processes. If a process does need to communicate its PM, there are mechanisms in place such negotiation between a PM and a process.
Evaluation
Once again, the evaluation of the system was sparse. The paper presented fundamentally good ideas about system design but failed to prove that the separation of policies and mechanisms is better than any other system design. The paper did acknowledge that they didn’t fully achieve the goal they set out to, in that they couldn’t completely separate the policies and mechanism in scheduling and paging.
Confusions
I was a bit confused on how PMs are created in the system. Is there one PM per user of the system? How many processes can a PM have? Does the user create these PMs? If the user does create the PMs, are they the ones that specify the policies or does it have to interact with the kernel in some way to specify the policy of the PM? Also, I was wondering how PMs are destroyed. Are they just destroyed once they don’t reference any processes?

Summary:
This paper talks about the various ways in which 'policy-mechanism separation' is implemented in the hydra system (specifically in the context of the process scheduling, paging and protection systems)

Motivation/Problem:
The 'Hydra' developers focused on moving as much of the policy out of the kernel and into higher level programs as possible.

Contributions/Solution:
Key points in Hydra's design are listed below:
- The hydra system implements a Kernel Multiprocessing system , which is a scheduler (inside the kernel) with parametrized policies. The parameters are provided by 'policy modules' (PM) which are processes which control the policies for other processes ( including scheduling, paging etc.)
- In scheduling, some amount of policy control is afforded to the PMs , with the parameters to the scheduler controlling the scheduling in the long term, and the short term scheduling decisions are made by the kernel (to avoid slow context switches).
- Paging is mostly handled automatically by the kernel .This is because, due to harware limitations and for efficiency purposes, paging and scheduling decisions are tied to each other and since short-term scheduling decisions are made in the kernel, that is the better place to handle automated paging and page replacement.
- In paging, we can influence the policies at a higher level from PMs and processes by changing the maximum no. of pages in core for a given process and by indicating individual pages as important (the authors state that this mechanism was not yet implemented).
- The protection system has the most clear-cut distinction between policy and mechanism since the 'capabilities' infrastructure (with objects and access rights) that it uses provides a very generic foundation on which we can build complicated protection policies. The only deterrent for flexibility here is that processes ( and LNSs / procedures) need to trust the PMs that schedule them. Even this is slighly mitigated by the fact that processes can read the metadata about their PM's and simply refuse to run if the PM is not trustworthy.

Evaluation:
- Even though the basic design that the authors set out to realize was that of a minimal kernel, due to many practical considerations ( eg: multiple untrustworthy PMs running in parallel) the authors have moved many policy decisions into the kernel's code either for efficiency or for arbitration purposes. They state that investigating the policy-mechanism separation problem further might lead to more minimalist designs.
- Since the paper focuses on the design of the system and not the implementation, understandably, performance metrics are not provided.

Confusions:
- Who decides the basic guarentees ( CPS pages, CPU cycles ) for the first level PMs? Is there a trusted 'root' PM which does this ( similar to the 'S' process in nucleus)?
- Who performs the RRload operation to fetch the page info of accessed addresses into relocation hardware before execution of each instruction? It is said that for the initial set up the information in LNS is used to do the RRLOADs (persumably by the kernel or PM) but what about subsequent instructions? Should the process take care of this?

1. Summary

This paper describes the design philosophy and implementation of three kernel mechanisms in the Hydra system. Hydra tries to leave policies around resources to user-programs, with the kernel only providing supporting mechanisms. However, due to certain practical realities, the kernel needs to implement some limited policy as well. The paper explains these trade-offs in great detail.


2. Problem

Incorporating policy-level intelligence in the kernel reduces the flexibility of the system. This policy might work for the ‘general-case’, but may fail for specialized user needs. The designers in HYDRA seek a separation of policies & mechanisms, where the user-programs can define policies for resources, using mechanisms provided by the kernel.


3. Contributions

HYDRA’s fundamental idea of separating policy & mechanism is a very powerful one, with wide applications in many aspects of software design. The paper tries to realize this separation for three resources - scheduling, paging & protection. For scheduling, HYDRA allows a user-program called Policy Module to decide the short-term scheduling for other user-processes. To ensure fairness across multiple PMs & fast scheduling decisions, HYDRA implements this mechanism as a ‘parameterized policy’. The parameters of this policy such as priority, time-quantum etc. can be decided by the PM to achieve different scheduling policies. Each process can have three sets of pages - it’s entire nameable space (LNS), the pages currently present in core memory (CPS) and pages directly addressable (64KB in this m/c). HYDRA provides mechanisms for a process to move pages between these sets. Since the CPS contents & sharing of pages are highly dynamic, the designers settle for the kernel implementing most of the paging & replacements. The PM can tune this using the max_CPS parameter for each process. The kernel implements a priority based replacement policy using the references to each page from process CPSs. Relative to paging & scheduling, HYDRA provides a clean separation of protection mechanisms and policy. Through the definition of capability, HYDRA provides isolation by default. For control protection, HYDRA exposes information about the PM to user-processes as well as negotiation of mechanisms between the two. Even though HYDRA does not achieve complete separation of policy-mechanism, valid reasons & arguments are made for their decisions which provide great insight into the complex interactions within an OS.

4. Evaluation

This paper has no evaluations. In fact, many mechanisms posited have not been implemented during the writing of this paper. However, convincing qualitative arguments are raised for each design decision.

5. Confusions

How is a PM selected for a process? The passage on Control protection makes sense, but I’m unable to intuitively grasp its significance. Can you give a modern-OS equivalent for this? If a process deems its PM to be sub-par, can it deny service to the PM? That sounds weird!

Summary:

The paper talks about the multiprocessing system Hydra and how they have achieved great flexibility by creating a separation between policy and mechanisms. There can be different policies implemented by user defined programs which in turn use the mechanisms provided by the kernel.

Problems:

The paper is trying to solve the issue where a particular program might not be given the exact resources it needs as the policies in other operating systems might not be tunable for a particular program.

Contributions:

The system HYDRA creates a separation between policy and mechanisms.
The policies are defined by user programs whereas the kernel decides on a fixed set of mechanisms which can be used by those policies. There are three important resources for which such a separation is required. One - processor time, which is achieved through mechanisms and policies for scheduling. Two - memory, which is achieved through mechanisms and policies for paging and finally - access to a resource i.e., protection.

The systems lets different user programs implement the scheduling policy using the mechanisms provided by the kernel. The kernel though takes care of short term scheduling due to the time taken for context switching in the policy programs. The policy programs provide the required information like the which processors to user, amount of time to be given for a process and priority of the process. Paging is achieved by deciding on the most appropriate replacement policy. One example would be to keep the pages of the top stack of LNS in the core memory or to keep pages of a high priority process. The kernel provides a guaranteed number of pages for each of the policy programs. The policy program gets to decide what is the maximum of those pages that should be assigned to each process. Finally protection is achieved through the normal protection bits of a capability and providing very little information about a process to the policy process. Also, the kernel provides protection to the process from erroneous policy programs using certain erroneous flags.

Evaluation:

The paper provides no details like if the process had its execution completed faster in HYDRA as compared to other system. No details are provided if the provided mechanisms are most efficient. The paper though provides examples where this flexibility would be of help.

Confusions:

How does a first process - say the first policy process gets scheduled. Is there a global PM which in turn starts another PM? Or does the Kernel take care of scheduling the PM? Also, how much of the resources are given to a PM? Is it like equally divided between the PMs?

Who decides to which PM a process should be assigned to? Is it that based on the requirements of a process, the kernel or the user decides the PM it should be assigned to?