I'm wondering whether we have or need a formalisation of how work might be
divided in future kernels.
The question I'm interested in is how the work gets split up among various
components at different levels within a single box (not SMP with many at
the same level, or various multi-box techniques), in particular how you
separate computation and I/O given some intelligence in devices other than
the main CPU (or SMP set).
There are a bunch of examples to look at:
IBM mainframe
"channel processors" do all the I/O
main CPU sets up a control block, does an EXCP instruction
there's an interrupt when operation completes or fails
VAX 782: basically two 780s with a big cable between busses
one has disk controllers, most of the (VMS) kernel
other has serial I/O, runs all user processes
various smart network or disk controllers
and really smart ones that do RAID or Crypto
I2O stuff on newer PCs
Larry McVoy's suggestion that the right way to run, say, a 32-CPU
box is with something like 8 separate kernels, each using 4 CPUs
If one of those runs the file system for everyone, this somewhat
overlaps the techniques listed above.
All of these demonstrably work, but each partitions the work between processors
in a somewhat different way.
What I'm wondering is whether, given that many drivers have a top-half
vs. bottom-half split as a fairly basic part of their design, it would
make sense to make it a design goal to have a clean partition at that
boundary.
On well-endowed systems, you then have the main CPUs running the top half
of everything, while I2O processors handle all the bottom halves and the
I/O interrupts. On lesser boxes, the CPU does both halves.
It seems to me this might give a cleaner design than one where the work
is partitioned between devices at some other boundary.
If the locks you need between top and bottom halves of the driver are also
controlling most or all CPU-to-I2O communication, it might go some way
toward avoiding the "locking cliff" McVoy talks of.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Mar 31 2001 - 21:00:24 EST