|
|
this is the list of suggested projects of Boston Univ linux course:
-------------------------------------------------------------------------------
* Implementing a real-time thread library:
o Provide ability to specify the thread scheduling policy.
o Provide a mechanism to specify/bound the delay of synchronization.
o Involves writing a new thread API.
o Possible support or "hooks" for interaction between kernel/user-level threads.
* A thread continuation mechanism:
o Implement an extension of Linux bottom-half handlers (or active message handlers -- SEE BELOW) to continue as threads that are scheduled for future execution if they do not complete in certain time bounds.
* A thread migration / load balancing system:
o Implement a mechanism to migrate threads to different hosts, in order to redistribute the demand for resources "more evenly" in a distributed system environment.
* Scheduler activations in Linux:
o Provide the mechanism for interaction between kernel/user-level threads.
o See [4] above.
* A Linux "upcall" mechanism:
o Essentially the opposite of a system call.
o Provide a means for the kernel to invoke handlers in user-space and pass parameters to these handlers.
o Provide a generalizable framework for implementing and scheduling handlers in different process/thread contexts.
* A real-time memory allocator / garbage collector:
o Provide a mechanism to preallocate, or bound the delay of allocation and de-allocation of memory.
o Possibly implement a replacement for the "slab allocator" in Linux.
* A distributed shared memory (DSM) system:
o Devise a scalable DSM system that supports application-specific consistency protocols.
o Provide a mechanism by which applications can customize the underlying DSM system to be more efficient / scalable.
* An event-based mechanism for implementing adaptive systems:
o Implement an event-channel mechanism that has the ability to pass "control" events between publishers (event generators) and subscribers (event handlers).
o Provide support for events to be delivered within an address-space and the same thread, between threads within the same address space, between address spaces on the same host, and between address spaces on different hosts.
o Support the ability to specify handler and event-generator functions.
o Support the multicasting of events to multiple subscribers.
o Provide "hooks" to schedule, dispatch, filter and transform events before they are ultimately delivered to subscribers.
* A data flow management mechanism:
o Similar to the event-based mechanism described above, construct a mechanism to manage the distribution of data, and functions that manipulate the data, in a distributed system or wide-area network. This would be applicable to, for example, web servers that wish to cache data at different locations, and/or perform some form of filtering or processing on the data as it is delivered along the path from source to destination.
* A QoS-based socket library:
o Modify the network subsystem in Linux to support per-socket-descriptor service disciplines.
o Extend the library and corresponding network subsystem to support "end-to-end" QoS guarantees on a per-socket basis.
* DWCS packet scheduling:
o See [10, 32] above.
o Implement DWCS as a packet-level service discipline in the Linux subsystem. A version of DWCS is already working as a replacement CPU scheduler in Linux.
* A heap-based priority scheduler in Linux:
o Alter the current "runqueue" data structure, which is a doubly-linked list, and replace with a heap data structure.
o Implement a priority-based scheduler, or use DWCS, to take advantage of the new runqueue structure.
o Evaluate the performance of the new scheduler (in terms of latency) to support large-scale processing.
o Alternatively, implement a separate runqueue data structure for real-time processes i.e. a class-based runqueue mechanism, similar to that provided by Solaris.
* Microsecond resolution timers for Linux:
o The University of kansas has a UTIME project, to implement microsecond timers in Linux.
o Integrate UTIME into a real-time scheduler such as DWCS and evaluate the ability to perform fine-grained scheduling.
* A QoS management framework ala QuO:
o Implement a framework for QoS management, either as a middleware layer "on top" of an OS, or by a combination of kernel extension and user-level libraries.
o My Dionisys work might be helpful here, and you could certainly port Dionisys to Linux.
* A real-time communications protocol:
o Implement a protocol that attempts to bound the delay of delivery of packets across a network (for example, like the now old XTP protocol).
* A feedback-control system/mechanism for flow/error/rate/congestion control:
o Implement a component-based system, like the SWiFT toolkit, or a specific instance, to evaluate the performance of an adaptive flow, error, rate or congestion control scheme.
* Active messages for Linux:
o Implement an active messaging system in Linux.
o The idea is that the first message in a flow of messages specifies the handler function to process the subsequent messages in the same flow.
o This is similar to a one-way, or asynchronous RPC-mechanism.
o Investigate different ways to implement active messaging e.g., at user-level or (partly) within the kernel, to improve performance.
o Investigate different ways to schedule/activate the message handler(s)
o Investigate different ways to avoid unnecessary copying of data i.e., from the network device to the kernel, and from the kernel to user-level where it is handled.
* An extension model for Linux:
o Taking the concepts outlined in systems such as SPIN, construct a secure/protected extension model in Linux.
o Extend the idea behind Linux kernel-loadable modules and provide a mechanism using which a user can safely link service extensions into Linux. |
|
IP卡
狗仔卡
发表于 2003-6-5 08:11:25
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡