On Mon, Mar 22, 2004 at 10:43:11AM -0500, Thor Lancelot Simon wrote:
> On Mon, Mar 22, 2004 at 10:00:18AM -0500, Thor Lancelot Simon wrote:
> > 
> > Having looked at (and instrumented) the I/O spreading rotor as it is in
> > your patch, I am not so sure it really does anything unless you happen
> > to have disks that can clear well upwards of 8,192 metadata operations
> > in a single second.  I implemented a very simple form of automatic
> > tuning for the spreading, and it _seems_ to work as intended.  I'm
> > attaching a patch.
> > 
> > However, there are some significant caveats:
> > 
> > 1) I am not _certain_ that all directory I/O appears in the syncer
> >    worklists as the vnode, of type VDIR, for each directory.  I have
> >    read and reread the code but I would like more people to look at
> >    this.
> 
> Hm.  I'm particularly unsure about this -- because when I run a benchmark
> that does two threads of heavy directory I/O, I see "dirburst" drop
> quickly to the minimum, even when I intervene with DDB and set it to the
> maximum.  Are all these directory writes, too, going on the mount point's
> vnode?  Or am I counting/tuning wrong in some other way?

Okay, running single- or two- thread extractions/removes of pkgsrc, I see
a consistent slight degradation of performance from the "rotor" patch I
sent, and "dirburst" always at 0x40, which is the minimum.  Can anyone
offer an explanation of why?  Given that I am seeing a total of only a
few hundred I/Os per second, I don't think a huge burst size as in Dan's
original patch is likely to change much of anything; so I am inclined to
regard this as a failed experiment, but I do not understand why.

-- 
 Thor Lancelot Simon	                                      tls@rek.tjls.com
   But as he knew no bad language, he had called him all the names of common
 objects that he could think of, and had screamed: "You lamp!  You towel!  You
 plate!" and so on.              --Sigmund Freud