assignment 2

We discuss the rationale and design of a Generic Memory management Interface, for a family of scalable operating systems. It consists of a general interface for managing virtual memory, independently of the underlying hardware architecture (e.g. paged versus segmented memory), and independently of the operating system kernel in which it is to be integrated. In particular, this interface provides abstractions for support of a single, consistent cache for both mapped objects and explicit I/O, and control of data caching in real memory. Data management policies are delegated to external managers. A portable implementation of the Generic Memory management Interface for paged architectures, the Paged Virtual Memory manager, is detailed. The PVM uses the novel history object technique for efficient deferred copying. The GMI is used by the Chorus Nucleus, in particular to support a distributed version of Unix. Performance measurements compare favorably with other systems.

How each emplements virtual memory?

Virtual memory is one of the most important subsystems of any modern operating system. Virtual memory is deeply intertwined with user processes, protection between processes and protection of the kernel from user processes, efficient shared memory, communication with IO (DMA, etc.), paging, swapping, and countless other systems. Understanding the VM subsystem greatly helps understanding how all other parts of the kernel work and interact. Because of this "Understanding the Linux Virtual Memory Manager" is a great guide in better understanding and working with the entire kernel

How each handles page sizes?

As computer system main memories get larger and processor cycles-per-instruction (CPIs) get smaller, the time spent in handling translation lookaside buffer (TLB) misses could become a performance bottleneck. We explore relieving this bottleneck by (a) increasing the page size and (b) supporting two page sizes. We discuss how to build a TLB to support two page sizes and examine both alternatives experimentally with a dozen uniprogrammed, user-mode traces for the SPARC architecture. Our results show that increasing the page size to 32KB causes both a significant increase in average working set size (e.g., 60%) and a significant reduction in the TLB's contribution to CPI, CPITLB, (namely a factor of eight) compared to using 4KB pages. Results for using two page sizes, 4KB and 32KB pages, on the other hand, show a small increase in working set size (about 10%) and variable decrease in CPITLB, (from negligible to as good as found with the 32KB page size). CPITLB when using two page sizes is consistently better for fully associative TLBs than for set-associative ones. Our results are preliminary, however, since (a) our traces do not include multiprogramming or operating system behavior, and (b) our page-size assignment policy may not reflect a real operating system's policy.

How each handles page fault?

The chip uses this 32 bit number to look up values in a page table. The value in this page table is the page's physical address (or an indication that the page is not available) and the accessibility of the page (read/write, user/kernel). The physical address actually maps to real memory in the computer that contains the data being accessed.
If the page is not available- a page fault occurs and the kernel either kills the process or loads the page from disk, depending on the value in the page table (which is up to the kernel to set)
If the page is readonly and a write is being attempted- a page fault occurs and the kernel either kills the process or does other clever stuff (also depending on data in the entry or elsewhere)
If the page is kernel and the processor is not in kernel mode- a fault occurs (can't remember if its a page fault or a GPF) and the kernel again decides what to do to the process.

How each handles working set?

No such concept. For all practical purposes, the app has virtually no control over its working set, unless the programmer has done something as fundamentally irresponsible as using VirtualLock, which almost always is a mistake, usually caused by fundamental misunderstanding of the programming problem. It is an API sufficiently obscure that it is hardly ever used anyway, and therefore it can usually be ignored as a possibility. If the app tops out at 32K files, it has exceeded some other limit, for example, some internal table that some programmer did a #define of 32768 (or some multiple thereof), or it is running some MS-DOS system, such as WIn98, that has built-in limits on how many objects you can add to a control. It has absolutely nothing to do with "working set".

How it reconciles thrashing issues?

Many interactive computing environments provide automatic storage reclamation and virtual memory to ease the burden of managing storage. Unfortunately, many storage reclamation algorithms impede interaction with distracting pauses. Generation Scavenging is a reclamation algorithm that has no noticeable pauses, eliminates page faults for transient objects, compacts objects without resorting to indirection, and reclaims circular structures, in one third the time of traditional approaches. We have incorporated Generation Scavenging in Berkeley Smalltalk(BS), our Smalltalk-80 implementation, and instrumented it to obtain performance data. We are also designing a microprocessor with hardware support for Generation Scavenging.

assignment 1

I.

A. Microsoft shall not retaliate against an OEM by altering Microsoft's
commercial relations with that OEM, or by withholding newly introduced
forms of non-monetary Consideration (including but not limited to new
versions of existing forms of non-monetary Consideration) from that OEM,
because it is known to Microsoft that the OEM is or is contemplating:

1. developing, distributing, promoting, using, selling, or licensing
any software that competes with Microsoft Platform Software or any
product or service that distributes or promotes any Non-Microsoft
Middleware;

2. shipping a Personal Computer that (a) includes both a Windows
Operating System Product and a non-Microsoft Operating System, or (b)
will boot with more than one Operating System; or

3. exercising any of the options or alternatives provided for under
this Final Judgment."

and

"B. Microsoft's provision of Windows Operating System Products to
Covered OEMs shall be pursuant to uniform license agreements with
uniform terms and conditions. Without limiting the foregoing, Microsoft
shall charge each Covered OEM the applicable royalty for Windows
Operating System Products as set forth on a schedule, to be established
by Microsoft and published on a web site accessible to the Plaintiffs
and all Covered OEMs, that provides for uniform royalties for Windows
Operating System Products, except that:

1. the schedule may specify different royalties for different language
versions;

2. the schedule may specify reasonable volume discounts based upon the
actual volume of licenses of any Windows Operating System Product or any
group of such products; and

3. the schedule may include market development allowances, programs,
or other discounts in connection with Windows Operating System Products,
provided that:

a. such discounts are offered and available uniformly to all Covered
OEMs, except that Microsoft may establish one uniform discount schedule
for the ten largest Covered OEMs and a second uniform discount schedule
for the eleventh through twentieth largest Covered OEMs, where the size
of the OEM is measured by volume of licenses;

b. such discounts are based on objective, verifiable criteria that
shall be applied and enforced on a uniform basis for all Covered OEMs;
and

c. such discounts or their award shall not be based on or impose any

criterion or requirement that is otherwise inconsistent with any portion
of this Final Judgment."

II.

A broad term for one of the fastest computers currently available. Such computers are typically used for number crunching including scientific simulations, (animated) graphics, analysis of geological data (e.g. in petrochemical prospecting), structural analysis, computational fluid dynamics, physics, chemistry, electronic design, nuclear energy research and meteorology.