Subject: Re: results from playing around with the new dirpref code
To: Jason R Thorpe <thorpej@wasabisystems.com>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-perform
Date: 09/03/2001 14:27:27
On Mon, Sep 03, 2001 at 10:40:50AM -0700, Jason R Thorpe wrote:
> On Mon, Sep 03, 2001 at 01:36:47PM -0400, Thor Lancelot Simon wrote:
> 
>  > Another observation: when you have to recycle a vnode, you get one that's
>  > basically chosen at random with regard to the current head position.  This
>  > is REALLY BAD.  To fix it, we'd need to index the vnode cache some other
>  > way than as a hash table, but the fix might give a really large performance
>  > increase in some cases.
> 
> Well, you can link a vnode into multiple tables, of course... the normal
> hash table plus a "inode position" table, or whatever.

Sure.  Some more thoughts on this (some of them thanks to Chuq's input):

1) We should probably have a per-CG circleq of vnodes.
2) We should cluster vnode cleaning by CG; after you've picked an initial
   vnode to clean, whether you're flushing or reusing, you should walk
   the circleq and clean it out.
2) We should separate flushing order from reuse order.  Rationale: when
   flushing, LRU is a reasonable policy, and the modified-LRU we get by
   clustering by CG is a reasonable optimization to prevent excessive
   seeks triggered by flushing.  In the reuse case, however, LRU is likely
   to pick the worst possible place to start; if a vnode is the least
   recently used, and the filesystem's data placement algorithm works, it
   is likely to be the *farthest from the current head position*.

Basically, it boils down to "cluster by CG whenever cleaning vnodes, but
pick where to start cleaning differently depending whether you're flushing
or reusing".

This should also avoid the situation where need to reuse triggers flushing
a lot better than the current state of things.

I don't see a way around having to pick a file/dir's location *when 
initially inserting the vnode into the cache*, however; we probably need
call into the filesystem to achieve this.  Otherwise, you can't actually
ever know where you'll place a vnode that represents a new file, which will
make choosing what to write out next a protracted exercise in insanity.

-- 
Thor Lancelot Simon	                                      tls@rek.tjls.com
    And now he couldn't remember when this passion had flown, leaving him so
  foolish and bewildered and astray: can any man?
						   William Styron