Microsoft Technology Licensing, LLC

Richard P Draves

Gilad Odinak

Paul J Leach

Richard F Rashid

Robert P Fitzgerald

Steven P Levi

Michael B Jones

Joseph S Barrera, Iii

Scott M Cutshall

Srinivasan Venkatachary

Keith R Vogel

Christopher Kevin King

A virtual memory system includes a hardware-implemented translation lookaside buffer (HTLB) as well as a software-implemented translation lookaside buffer (VTLB). The VTLB is in the system's unmapped memory. The system further includes a plurality of address maps, corresponding to an operating system kernel and to individual tasks executing within the system. The kernel has an address space which includes both mapped and unmapped memory. The address maps corresponding to the individual tasks are stored in the mapped memory of the kernel's address space. The address map corresponding to the kernel itself, however, is stored in the kernel's unmapped memory. HTLB misses are handled by referring to the VTLB. VTLB misses are handled by referring to an appropriate one of the address maps. The code for handling these misses resides in unmapped memory of the kernel's address space. This arrangement prevents recursive TLB misses, without requiring permanent or &ldquo;wired&rdquo; VTLB entries. Because there are no permanent VTLB entries, the VTLB can have a simple and efficient structure, and its size can be bounded. As a further features, the address maps are associated with both spin locks and mutex locks. A routine which modifies an individual address map first acquires the mutex lock associated with the address map and performs initial examination of the address map. Once the routine is ready to make actual modification, it also acquires the spin lock. By having the two types of locks, the majority of the routine can be preemptible. Only the portion of the routine which actually modifies the address map needs to be non-preemptible.

Virtual memory system and methods

A computer system includes a plurality of client processes executing in respective address spaces and at least one server process executing in a different address space than the client processes. The server process has one or more available server objects for potential use by the client processes. The server objects are accessible by the client processes through a plurality of server object interfaces dynamically created in response to demand for said interfaces by the client processes. The server object interfaces are destroyed when there is no further demand for them. Each object interface can be simultaneously held for use during at least a portion of its lifetime by more than one of the client processes. The computer system further includes one or more client-side ping managers and at least one server-side ping manager. Each client process registers interfaces it is holding for use with an associated client-side ping manager. The server-side ping manager is associated with the server process and stores one or more interface lists indicating server object interfaces held for use by client processes. The server-side ping manager has a ping manager object interface available to the client-side ping managers. Each client-side ping manager accesses the server-side ping manager through the ping manager object interface to maintain an interface list with the server-side ping manager indicating server object interfaces which are registered with the client-side ping manager. Each client-side ping manager monitors whether any of its registered client processes have terminated, and automatically unregisters the interfaces of any such client processes which have terminated. The server-side ping manager notifies the server process of any server object interfaces which are no longer included in the interface lists of the server-side ping manager so that those interfaces can be destroyed.

Efficient inter-process object and interface pinging

Routers and methods for optimal routing table compression

A computer system has a microprocessor that can execute in a non-privileged user mode and a privileged kernel mode. A user virtual address space is used when the microprocessor is in the user mode, and a kernel virtual address space is used when the microprocessor is in the kernel mode. Each of the address spaces has the same range of virtual addresses that is designated for shared components. The user virtual address space is mapped to an offset position within the kernel address space. When a user process calls a kernel function with a pointer argument, the pointer is biased before being dereferenced to account for the offset of the user address space within the kernel address space. This allows for sharing of position-dependent code, while still allowing the kernel to access the entire user address space.

Sharing executable modules between user and kernel threads

A method and system that allows a client process to invoke a remote procedure. An operating system maintains a table with an entry for each remote procedure. Each entry of this table contains a signature that specifies a format in which parameters are exchanged between the client process and the remote procedure. When the client process requests the invocation of the remote procedure, the operating system creates a stack for the remote procedure. This stack is then mapped into the operating system's address space. By mapping the remote procedure's stack in this fashion, the operating system can simultaneously access the client's stack and the remote procedure's stack. The operating system then copies, in accordance with the remote procedure's signature, parameters directly from the client's stack to the remote procedure's stack. Once the parameters are copied, the remote procedure executes using the data contained on its own stack. When the substantive execution of the remote procedure is complete, the remote procedure traps back to the operating system. The operating system then copies, in accordance with the remote procedure's signature, return parameters from the remote procedure's stack to the client's stack. Once these parameters have been copied, the operating system returns to the client process so that the client process can continue with its execution.

Method and system for invoking remote procedure calls

A method and system for scheduling the use of a computer system resource using a resource planner and a resource provider is provided. In a preferred embodiment, a resource is scheduled for use by a plurality of consumer entities. Each consumer entity may request the commitment of a share of the resource. The method and system utilizes representations of resource usage policy, present commitments of shares of the resource, and present commitments of specified amounts of the resource over specified period of time. The method and system first receives a request from a consumer entity for the commitment of a specified share of the resource. In response, the method and system determines whether the specified share of the resource should be committed to the requesting consumer entity. This determination is based on the representations of resource usage policy and present commitments of shares of the resource. If it is determined that the specified share of the resource should be committed to the requesting consumer entity, then the method and system modifies the representation of present commitments of shares of the resource to commit the specified share of the resource to the requesting consumer entity. The method and system then schedules the use of the resource by the plurality of consumer entity based on the modified representation of present commitments of shares of the resource.

Method and system for scheduling the use of a computer system resource

The invention includes a computer system having a processor that executes program instructions in privileged and non-privileged execution modes. A user stack is used when the processor is executing in the non-privileged execution mode. A kernel memory stack is used when the processor is executing in the privileged execution mode. The kernel memory stack can grow and shrink dynamically as it is used by its associated thread, through the use of allocate-on-demand memory. A stack overflow handler is executed from within the kernel to resolve allocate-on-demand faults. The stack handler uses only fixed-size memory stacks.

Variably-sized kernel memory stacks

A computer system includes physical memory, a virtual memory system, and a protected operating system kernel. The kernel has kernel functions that accept and use virtual memory addresses from user processes. When an invalid virtual memory address is used by a kernel function, the memory address is automatically mapped to a scratch location in physical memory, so that the kernel function accesses the scratch location rather than generating an exception.

Virtual memory scratch pages

A virtual memory system includes a hardware-implemented translation lookaside buffer (HTLB) as well as a software-implemented translation lookaside buffer (VTLB). The VTLB is in the system's unmapped memory. The system further includes a plurality of address maps, corresponding to an operating system kernel and to individual tasks executing within the system. The kernel has an address space which includes both mapped and unmapped memory. The address maps corresponding to the individual tasks are stored in the mapped memory of the kernel's address space. The address map corresponding to the kernel itself, however, is stored in the kernel's unmapped memory. HTLB misses are handled by referring to the VTLB. VTLB misses are handled by referring to an appropriate one of the address maps. The code for handling these misses resides in unmapped memory of the kernel's address space. This arrangement prevents recursive TLB misses, without requiring permanent or 'wired' VTLB entries. Because there are no permanent VTLB entries, the VTLB can have a simple and efficient structure, and its size can be bounded. As a further feature, the address maps are associated with both spin locks and mutex locks. A routine which modifies an individual address map first acquires the mutex lock associated with the address map and performs initial examination of the address map. Once the routine is ready to make actual modification, it also acquires the spin lock. By having the two types of locks, the majority of the routine can be preemptible. Only the portion of the routine which actually modifies the address map needs to be non-preemptible.

Virtual memory system with hardware TLB and unmapped software TLB

A method and system for scheduling the execution of threads using optional time-specific constraints is provided. In a preferred embodiment, a scheduler schedules the execution of a plurality of threads each specifying either a percentage processor time scheduling constraint, indicating that a certain percentage of processor time should be dedicated to the execution of the thread, or a deadline scheduling constraint, indicating that a specified quantity of work should be done by the thread by a specified time deadline. For each thread specifying a percentage processor time scheduling constraint, the scheduler determines a restart time corresponding to the percentage processor time scheduling constraint. For each thread specifying a deadline scheduling constraint, the scheduler determines a restart time corresponding to the deadline scheduling constraint. The scheduler then utilizes the determined restart times for scheduling the threads by selecting the thread having the earliest restart time for execution.

Method and system for scheduling the execution of threads using optional

A method and system for allowing processes to access resources. A kernel of an operating system maintains a system-wide resource table. This resource table contains resource entries. When a resource is allocated, the kernel generates a key for the resource. The key is a very large number so as to prevent a malicious process from gaining unauthorized access to the resource. The kernel also hashes the key to generate an index into the resource table that is used as a handle. The kernel stores the key in a resource entry that is indexed by the handle. The handle.backslash.key pair is sent to a process. The process accesses the resources by passing handle.backslash.key pairs to the kernel. The kernel compares the passed key with a key that is stored in the resource entry referenced by the passed handle. When the stored key and the passed key match, the process is allowed to access the resource. When the stored key and the passed key do not match, the kernel rehashes the passed key to generate a new handle. The kernel then searches starting at the index of the new handle for a resource entry with a key that matches the passed key. When a key matches the passed key, the process is allowed to access the resource, and the index for the resource entry is returned to the process so that the process can use the index as a handle to access the resource on subsequent resource access requests. When the passed key does not match a key, the process is denied access to the resource.

Growing community of inventors

Seattle, WA, United States of America

Richard P Draves