--- wikisrc/projects/project/buffer-queue.mdwn 2011/11/06 21:08:23 1.2
+++ wikisrc/projects/project/buffer-queue.mdwn 2014/02/27 06:57:54 1.3
@@ -11,18 +11,24 @@ difficulty="medium"
duration="2-3 months"
description="""
-NetBSD has a fixed, kernel-wide upper limit on transfer size, which is currently
-set to 64k on most port. This is too small to have good performances on modern
+NetBSD has a fixed, kernel-wide upper limit on transfer size, called MAXPHYS, which is currently
+set to 64k on most ports. This is too small to perform well on modern
IDE and SCSI hardware; on the other hand some devices can't do more than 64k,
-and in some case are even limited to less (the Xen virtual block device for
+and in some cases are even limited to less (the Xen virtual block device for
example). Software RAID will also cause requests to be split in multiple
smaller requests.
-NetBSD would greatly benefit from a more intelligent buffer queue management
-between the block device drivers and the higher levels (the framework here
-currently only applies some selectable algorithm to sort the queue). This
-framework should be able to split buffers too large for a device into smaller
-ones, or aggregate multiple contiguous requests into a larger one. This will
-most probably require change to at last some block device drivers.
+There is currently work in progress to make MAXPHYS configured at
+runtime based on driver capability.
+
+This project originaly suggested instead to make the buffer queue
+management logic (which currently only sorts the queue, aka disksort)
+capable of splitting too-large buffers or aggregating small contiguous
+buffers in order to conform to device-level requirements.
+
+Once the MAXPHYS changes are finalized and committed, this project may
+be simply outdated. However, it may also be worthwhile to pursue this
+idea as well, particularly the aggregation part.
+
"""
]]