On Sun, 11 Jul 1999 02:57:22 -0300, Jeff Dike <jdike@karaya.com> said:
> 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.
If there is that much contention for the code then the resulting
cross-CPU communication will be at least as expensive as the lock
contention you were suffering in the first place!
> 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.
Yes, some of the non-Intel Linux porting projects have tried using the
idle thread to pre-zero pages for get_free_page(), and have seen big
performance improvements as a result.
> Before writing a page out to swap, compress it.
Ouch, I'd hate to see the CPU cost. This is fine for a single-user box
with one swapping task, but gets really expensive as soon as you are
multitasking.
> 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.
You cannot do this for the read() system call without playing really
expensive virtual memory tricks, but an alternative API for real
asynchronous IO is already being talked about.
> Moving data from one process to another by remapping pages would be a
> lot more efficient than by copying the data.
No, VM tricks can be very expensive (especially with threaded programs
on SMP, where every VM update has to involve a cross-CPU interrupt to
invalidate TLB caches on other CPUs). We actually tried this for pipes
once and it wasn't that good.
> 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.
For every such definition you'll find a genuine program which triggers
the killer. :)
> /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.
dmesg/syslog already offer this: you can specify messages to be of
debugging priority and only log higher priority messages to syslog.
"dmesg" will tell you all of the recent unlogged messages.
> A pseudo-filesystem for exposing internal process state
Ooh, like /proc fs?
--Stephen
-
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/