Messages in this thread |  | | | Subject | [RFC] - Some notions that I would like comments on | | Date | Sun, 11 Jul 1999 02:57:22 -0300 | | From | Jeff Dike <> |
| |
I've accumulated a number of ideas which may or may not be reasonable to try implementing. I decided I wasn't going to have anywhere near the time necessary to implement them, so I might as well tell the list and have it tell me which of these are truly wacko and which might be worth trying. Below is a short synopsis of each. These are expanded on in greater detail at http://www.mv.com/ipusers/karaya/ossf/ossf.html, so if the stuff below seems incomplete and inadequate, check out the web page.
Scalability through specialization On an SMP system, when a critical section of code is being hit often enough that around one CPU equivalent is being lost to the locking overhead, then it might be worthwhile to have one processor stop running processes and start running a thread which does nothing but handle that critical section.
Making idle threads earn their living This involves finding parallelism in the kernel and getting an otherwise idle processor to handle one of the parallel chunks of work.
Compressive paging Before writing a page out to swap, compress it.
Speculative I/O When a process does a read, the kernel could schedule the I/O and return success before it completes. This would allow the process to start work before the read has finished.
IPC through page remapping Moving data from one process to another by remapping pages would be a lot more efficient than by copying the data.
Runaway process detection Detecting runaway processes and putting them to sleep might be a nice little feature to add to the kernel. The web page contains what I think is a correct algorithm for determining that a process is a runaway.
An extra channel for kernel messages /proc/<pid>/kmsg would be a good idea. This would contain messages pertaining to a process which are not important enough to go into the message log, which might not be useful in five minutes, but which the user might be interested in now.
A pseudo-filesystem for exposing internal process state This would be a uniform, generic way to attach real-time monitors to cooperating processes.
Jeff
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |