On Mar 6, 2005, at 5:38 PM, Chuck Silvers wrote:

> overall, this exercise has exposed a number of issues that we should 
> address:

Nice analysis, Chuq.  I think it's worthy opening PRs for all of these 
issues.  I also think it might be worth investigating using a "cache 
queue" strategy like FreeBSD has, and maybe also re-investigating 
generational scavenging for the page daemon.

>
>  - our default memory-usage-balancing isn't good for this kind of 
> application.
>    it's unclear that the current set of sysctl knobs is adequate.
>  - the buffered I/O code needs to become smart enough to avoid reading 
> pages
>    when they're just going to be overwritten.
>  - the read ahead code should avoid reading ahead until there is 
> evidence of
>    sequential access.
>  - the read code should make sure that medium size (more than a page, 
> smaller
>    than MAXPHYS) reads use the minimum number of disk I/Os (ie. 1) to 
> fetch
>    the data.
>  - the fsync() / vm-pager-put code needs to be able to find pages 
> efficiently,
>    which means tracking page dirtiness indexed by uvm_object.
>  - we ought to implement direct I/O with something to allow concurrent 
> reads
>    and writes, since that performs best for database-like applications.
>
>
> -Chuck
>
-- thorpej