On Wed, 6 Mar 2002, Jason R Thorpe wrote:

> On Wed, Mar 06, 2002 at 01:17:52PM -0800, Bill Studenmund wrote:
>
>  > This problem is just a cache/hash problem. I think we can fix it (or break
>  > it :-) independantly of the other problem. The first thing that comes to
>  > my mind is to make sure that LOG2_SIZEVNODE is still right; I'm not sure
>  > if it's been adjusted since UBC (and the addition of the struct uvm_obj at
>  > the front of the struct). That being wrong will certainly make the hash
>  > not work right.
>
> Hm, if it's LOG2_SIZEVNODE ... does that mean that the hash code also
> relies on the vnodes being allocated by a power-of-2 allcator?  Vnodes
> come from a pool now, so that assuption would also be broken.

Not sure. Here's the code, followed by my thoughts on what it's doing:

#define LAYER_NHASH(lmp, vp) \
        (&((lmp)->layerm_node_hashtbl[(((u_long)vp)>>LOG2_SIZEVNODE) & \
                (lmp)->layerm_node_hash]))

This macro gives us a pointer to the right hash list. It does it by taking
the address of the vnode, shifting it to toss out the bits which will
probably be zero (or uninteresting) because of the size of struct vnode,
and then masking that number with the bit mask for the hash table.

So is that the right thing to do with the pool allocator?

Take care,

Bill