On Mon, Sep 11, 2006 at 10:32:56AM -0500, Sumantra Kundu wrote:
> [...]
> 
> To highlight a scenario where such an uvm_cca might be useful, let me
> take a leaf out of Bill's email:
> 
> "Consider a hard disk that can write about 15 MiB/sec (2^20 MB, not 10^6
> MB). Now consider this disk being the destination of a video capture
> stream. Non-high-definition TV needs less than 4 MB/sec, so the disk can
> capture the video easily, as long as we keep it flowing.
> 
> Now say we have a video capture app going, and other things end up writing
> to the disk. Some of this may be metadata, some of this may be other
> programs. The problem is if we have to seek much. Seek times are rated at
> between 6 and 9 ms. Let's say 4 ms for now, to under-estimate. 4ms
> represents almost 63k worth of data. So something that means we have to
> seek somewhere other than the video stream then seek back puts an 8 ms
> delay in our write, which is 126k or so. So if we allow too many little
> writes in, we can mess ourselves up."
> 
> 
> Comments/Feedbacks/Directives are appreciated,

What kind of interraction does UVM have with underlying devices ?
what kind of mechanism are used to start writes ?

In light of recent discussion about vnd issues, I think making the device's
buffer queue bounded could make sense, and we could have the strategy routine
return EAGAIN when the queue size limit is reached (the same way we have
bounded queues in the network stack). If we have a way to make this
information up to UVM, then we have the information needed to throttle writes
to this device.
The we can have some scheduling in UVM to prioritize requests between
processes.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--