[RFC] - Some notions that I would like comments on

Jeff Dike (jdike@karaya.com)
Sun, 11 Jul 1999 02:57:22 -0300


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/