DragonFly kernel List (threaded) for 2005-12
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Plans for 1.5
Date:
2005年12月17日 14:21:45 -0800 (PST)
Starting in January, major surgery is going to occur on HEAD. PEOPLE
NEEDING STABLE SYSTEMS SHOULD EXPECT TO STICK WITH THE 1.4 RELEASE
FOR A GOOD 3-4 MONTHS!
-----------------------------------------------
STAGE 1 - Networking MPSAFE work
Starting early January!
* Jeff's parallel routing code will be integrated
* TCP and UDP threads, and the network interrupt code will be made MPSAFE
with the exception of the firewall and IP filter code.
* The mbuf subsystem will get a makeover (Jeff and I will be embedding
a message structure in the mbuf header to avoid a per-packet malloc
and greatly improve performance).
NOTE: I will not personally be working on the firewall/filter code
so once the above items are stable I will be soliciting developers to
work on those subsystems (to make them MPSAFE). The network paths will
not be entirely MPSAFE until those last bits are done.
I am deliberately choosing a chewable piece of work for stage 1 so I can
get it done and move on to stage 2.
-----------------------------------------------
STAGE 2 - I/O Subsystem
Starting early February!
* I will be designing and implementing our cache coherency management
system (CCMS). Since cache coherency must be tightly integrated into
the management of offset ranges for files, block devices, VM pages,
and so forth, this technology will also serve as an offset/range
locking subsystem for high level operations such as read() and
write(), as a locking and cache coherency mechanism for mid-level
subsystems such as the buffer cache, and as a cache coherency
mechanism for the VM system.
This will be a crucial step in allowing us to implement cache-coherency
across physical machines. For example, the ability to have fully
coherent mmap()'d shared memory across physical machines.
CCMS will be vnode-based.
* CCMS will be used to encapsulate read(), write(), and truncate().
* The buffer cache will be converted from being block-number-based to
being offset-range-based and will use CCMS for management.
* The VM subsystem will be converted to using CCMS for management.
To cut down on clutter, ranges of pages may be managed under the
same CCMS lock and may be broken down or merged as necessary to
control kernel memory use.
* All VM Objects will be given vnodes for management purposes, including
anonymous memory objects.
This is a precursor to being able to do process migration across
machines.
* All VNODES will be given a mandatory VM object for CCMS and buffer
cache management purposes.
Alternatively we will do away with the VM_PAGE->VM_OBJECT mapping
entirely and instead simply have a VM_PAGE->BUFFER_CACHE mapping,
which might actually be better.
* read() and perhaps write() will be modified to use CCMS to directly
access VM OBJECTS and/or the buffer cache, allowing cached data to
be directly copied to the user process without having to run
through the VFS subsystem.
* I intend to construct a fully cache-coherent Inter-machine transport
layer for VNODEs using TCP. This will allow NFS-style cross mounting
between DragonFly hosts that are 100% cache coherent.
NOTE: I am deliberately not listing conversion of the I/O subsystem from
mapped buffers to page lists (XIO's) because I feel this might be too big
a piece of bite off with the other things I want to do in this stage,
and I don't want to hold up STAGE 3.
-----------------------------------------------
STAGE 3 - ZFS PORT
Starting March or April!
I am really quite impressed with Sun's ZFS. People wishing to look at
the Sun ZFS code can find it on LEAF in the OpenSolaris source tree:
cd /archive/OpenSolaris-20051207/usr/src/
common/zfs
uts/common/fs/zfs
uts/sparc/zfs
uts/intel/zfs
cmd/fs.d/zfs
cmd/mdb/common/modules/zfs
cmd/mdb/intel/ia32/zfs
cmd/mdb/intel/amd64/zfs
cmd/mdb/sparc/v9/zfs
cmd/zfs
I have perused the ZFS code and I am impressed. Very impressed! It is
well documented, nicely modular, and easy to read.
I am tentatively scheduling the port for March. It may occur sooner or
later then that (hopefully sooner), but I just don't know how hard
STAGE 2 is going to be.
I really want to start the port immediately, but I think I am really
going to need userland VFS working for such a port to be able to proceed
at a good clip.
-Matt
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]